This message was deleted.

# announcements

[Slackbot]

This message was deleted.

[Corey Johnson]

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?

[Animesh Sahu]

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

[Corey Johnson]

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

[reik.schatz]

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

[Animesh Sahu]

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

[reik.schatz]

https://github.com/npryce/goos-code-examples/blob/master/testing-multithreaded-code/src/book/example/threading/races/MultithreadedStressTester.java

[reik.schatz]

this is the original one. only did it in kotlin

[James Richardson]

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

[James Richardson]

That code has a couple of bugs in it but you've prompted me to fix them..you may not hit them