Fork me on GitHub

@surreal.analysis 1) in the future you still might want to optimize the test suite and run tests in parallel using all the cores, e.g. using runner instead of lein test. 2) the described approach probably goes against the rule of "Don't mock code you don't own". Here's a nice summary about this rule of thumb:


@metametadata Thanks for more insight. In this case, I think mocking might still be the best case, because all I’m doing is adding a sleep statement. That is, it’s async code that interacts with JavaScript in a running web browser. We have no way of knowing when the code is complete, and some timing issues were present in production that aren’t present on my machine. By adding a single test that made the execute-javascript function execute the first part, then sleep for awhile, I could reproduce the issue and add a failing case that I then fixed


I’d strongly recommend never, ever using sleeps to make async things pass in tests


put something in the mock that you can join on, e.g. deref a promise


In this case it looks like it was impossible because the tested implementation also doesn't use any callbacks/promises/etc.. But I'm not sure I correctly understood the scenario.


fwiw, it is testing selenium interactions. So yeah, lots of external state that are non-deterministic.