On 4/26/19 1:33 PM, Steve Dougherty wrote: > Yes, mocking time will be helpful. It’s not clear to me how many > places that will be of use, or whether mocking would still be viable > in integration tests instead of just unit tests, but it’s definitely a > good tool to have. Do you know if JUnit has anything that can help > with that? It seems like a common enough need that it might.
I just checked if there is anything included in JUnit but it doesn't seem so. According to answers on stackoverflow, Java 8 provides an abstract class Clock that can be used instead of creating a custom interface [1]. To get an instance of the Clock class, one could either add a corresponding constructor parameter to the class that uses it or add a method getClock() to the Node class/interface. Alternatively, there is a framework called PowerMock [2] that can be used to instrument calls to System.currentTimeMillis() directly[3]. PowerMock still seems to be actively maintained (last commit was 5 days ago) but I don't know for how long. So, using the Clock class seems to be the more reliable solution to me. [1] https://stackoverflow.com/questions/2001671/override-java-system-currenttimemillis-for-testing-time-sensitive-code#answer-26570951 [2] https://github.com/powermock/powermock [3] https://stackoverflow.com/questions/28219698/powermock-with-final-class-system-and-static-method-currenttimemillis > Testing concurrent things may require more Conditions for threads to > wait on. It’s not clear to me how much effort that will require to be > viable, or how best to expose them. I also don't yet have a good feeling about the effort. I will pick a class like LocationManager and try to write some test cases for it. -- Martin Byrenheid Scientific Assistant Technische Universität Dresden Faculty of Computer Science Institute of System Architecture Chair of Privacy and Data Security 01062 Dresden Tel.: +49 351 463 38235 GPG : F144 FBCD F0C2 257A 87ED CFDE 24EB E684 D0BE E785
