https://kotlinlang.org logo
#announcements
Title
# announcements
s

Slackbot

08/07/2019, 2:35 PM
This message was deleted.
c

Corey Johnson

08/07/2019, 2:48 PM
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?
a

Animesh Sahu

08/07/2019, 2:52 PM
@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.
c

Corey Johnson

08/07/2019, 3:04 PM
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
r

reik.schatz

08/07/2019, 3:07 PM
I wrote a Kotlin version of the Nat Pryce’s famous
MultithreadedStressTester
🙂
a

Animesh Sahu

08/07/2019, 3:11 PM
@reik.schatz can you provide a link to that tester?
this is the original one. only did it in kotlin
j

James Richardson

08/07/2019, 4:50 PM
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"...
That code has a couple of bugs in it but you've prompted me to fix them..you may not hit them
4 Views