When writing integration tests for my Rustnish reverse proxy project I have hard-coded port numbers in tests. This is not ideal because it is hard to keep track of which port numbers have already been used and which ones are available when writing a new test. Because Rust's test runner executes test cases in parallel it is important to coordinate which test uses which ports so that there are no clashes that break the tests.

One obvious solution to this problem would be to disable parallel test execution with cargo test -- --test-threads=1. But we want to cover program and test isolation with our test so this is not really an option.

unwrap() is a useful tool in Rust but is also bad practice in production code that should not abort with unpredictable panics.

Therefore my goal 4 for Rustnish is full integration tests with no panics allowed:

Expand the integration tests to confirm that the reverse proxy is working as expected. Add tests with broken HTTP requests to cover error handling of the reverse proxy. All unwrap() calls in none test code should be removed and covered by proper error handling.

Since my first blog post where I constructed a server with Hyper some time has passed and there is now a new version of the library that is based on Tokio. My goal 3:

A new version of the Hyper library has been released which is based on the Tokio library. Convert the existing code to use that new version and provide one integration test case.

Tokio handles input/output asynchronously, which makes setting up a server more complicated. The benefit is more efficient parallel execution with a non-blocking event loop.

I already wrote about using Eclipse for Rust development but after trying Visual Studio Code (VSCode) I think it is slightly better than the Eclipse integration:

• when the cursor is at a variable the same variable is highlighted elsewhere.
• tooltip popups when hovering over variables, functions, methods.
• better native support for Git and Markdown files

Syntax highlighting, autocompletion, Ctrl + Click on functions and auto-formatting of course also work in VSCode as you would expect from an IDE.

In my first post I wrote a quite fragile, minimally working prototype that uses many unwrap() calls thereby raising lots of panics during execution. Implementing and verifying proper error handling requires testing. I don't want to do unit testing yet because that would require research about complicated mocking techniques and dependency injection in Rust. Instead, I would like to do integration testing of the whole application to prove that the end result is working as expected.

Update: New blog post about choosing Visual Studio Code for Rust because of better IDE support.

In my first blog post I was starting out with Atom editor but quickly realized that it is lacking features of Integrated Development Environments (IDEs). I need to be able to click on functions and data types to jump to their definitions and was not able to get that working in Atom.

Rust is still very alien to me and I want to write a bit of code in it to get a feeling of the concepts and restrictions it enforces.

What is the appropriate response if a fellow woman pulls you aside and says "Go easy on this code review, she is a woman after all and already gets a lot of shit."? Of course it is "Sure, this will be my friendliest code review ever!".

Here are the slides and the video of our DrupalCon Dublin 2016 talk "Automated Testing: PHPUnit all the way".

Here is the video of my DrupalCon Asia 2016 talk "How to publish a module on drupal.org".