concurrentunit
concurrentunit copied to clipboard
Toolkit for testing multi-threaded and asynchronous applications
https://github.com/actions/setup-java/releases/tag/v3.0.0 https://github.blog/changelog/2021-08-30-github-actions-setup-java-now-supports-dependency-caching/
https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/
In some use cases, it would be nice to be able to capturing assertion failures to report later without necessarily waiting on anything. Ex: ```java runInThread() -> { waiter.assertTrue(false); });...
As you yourself apparently noted at https://www.planetgeek.ch/2009/08/25/how-to-find-a-concurrency-bug-with-java/ : > This pattern looks similar to what was generalized into the ConcurrentUnit library for testing multi-threaded code But there's one thing missing,...
There's now a standard for exceptions in testing frameworks that IDE's can universally understand. Converting to these assertions would make the exceptions reported by this tool more useful. https://github.com/ota4j-team/opentest4j
Idea from here http://stackoverflow.com/questions/30778485/whats-the-correct-way-to-test-runnables-that-can-not-be-directly-seen-by-a-ju/30789208#30789208 Handle failures in threads running code that cannot be modified.
Consider an API to wrap closures that can handle any failures and re-throw them in the main test thread. Ex: ``` messageBus.registerHandler(waiter.handleFailures(() -> msg -> { throw SomethingBadException(); }); ```
Add a method to verify resumes - ex: `verifyResumes(int)`. This could be useful to assert that resume is not called more than expected, such as after await is unblocked.
There's never really an appropriate time to wait forever in a test. Therefore, await() should be deprecated.