This message was deleted.

In my experience; it’s easier to write functions that will be called from the thread; so that you can then unit test those functions. Would that work for you or nah?

@Corey Johnson actually my project is based on threads e.g. https://github.com/Animeshz/threadpool/blob/master/src/test/kotlin/com/animeshz/threadpool/PoolTest.kt testing these.

I see.. Maybe you could create an extension function for your Pool class to list what threads are currently in the pool; and then assert against that list? I don’t quite understand what this is trying to test unfortunately

I wrote a Kotlin version of the Nat Pryce’s famous

MultithreadedStressTester

🙂

@reik.schatz can you provide a link to that tester?

Test the functionality of simple non threaded classes. Then test that the threading works. You should be able to assert on the side effects of the threaded code. You can also use things like a testable executorservice. There is one in https://github.com/time4tea-net/tea-time/blob/master/src/main/java/net/time4tea/time/executors/test/ControllableSimpleScheduledExecutorService.java - this allows you to control the passage of time. So you can then say "advance clock 5ms" "assert some side effect"...