@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 https://github.com/weavejester/eftest 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: https://github.com/mockito/mockito/wiki/How-to-write-good-tests#dont-mock-type-you-dont-own

@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.