rustlings-solutions/src
bors ffb165ce26 Auto merge of #140 - cjpearce:fix/test-race-condition, r=komaeda
Fix intermittent test failure caused by race condition

First public pull request 😬

There's an intermittent integration test failure when you use multiple test threads (at least for me on a mac). I narrowed it down to two tests each spawning a process using `Command` which then try to compile the same file at the same time. If the timing doesn't work out, they both try to compile, and then one process runs `clean` before the other can run the executable - causing a panic.

![Screenshot 2019-04-07 at 19 54 55](https://user-images.githubusercontent.com/3453268/55688324-20520980-596f-11e9-8474-5215d61a4387.png)

You can prevent it from happening by running with a single thread (`cargo test -- --test-threads=1`), because the `Command` blocks. That's not a particularly good solution though because it's not something you can configure in `Cargo.toml`.

I considered making the affected tests just run serially, but it occurred to me that this could also happen if someone accidentally runs rustlings in watch mode in two terminals without realising it. I wound't consider this that unlikely given it's a tool for learning.

I fixed it by ensuring that the executables made from separate processes don't conflict by appending a process id to the output executable name. I also extracted the commands into a single file next to `clean` so that we don't have to repeat the generated file name everywhere and risk missing something.
2019-04-07 22:37:34 +00:00
..
main.rs Fix test failing due to panic 2019-04-07 20:13:04 +01:00
run.rs Extract command builders into util 2019-04-07 17:26:01 +01:00
util.rs Add process id to temp file name 2019-04-07 17:28:51 +01:00
verify.rs Extract command builders into util 2019-04-07 17:26:01 +01:00