Test Fests are hackdays organised around the world with a focus to improving the quality and coverage of tests in OpenJDK. In particular IBM, Oracle and Java User Groups are pushing these days.
Running a Test Fest
- Spend less time up front explaining OpenJDK procedure and getting people to write tests
- Get people to build Your Own Environment ahead of time
- Pick specific areas to focus on for writing tests, e.g. The Base64 class and JSR 310 (Date and Time).
- Narrow down the scope for these events as much as possible and perhaps even pick 1-3 classes to focus on that you know aren't tested.
- Grepping source code for "TODO: more tests"
What didn't work
- Code Coverage tools are lacking and reports unpublished - TBA Pavel from RedHat is working on this
- Still need manual work to marshall commits into openjdk (should be solved by betterrev)
- Testing JSR-310 required quite a bit of explanation since the things that are least tested are Japanese and Islamic calendaring systems which have a lot of local domain knowledge. We should probably avoid this kind of stuff in future.
Types of activities
Rules for writing tests
- Think before you code! - Have a specific goal, target specific methods.
- Make tests understandable - Fill in the summary tag, be clear and make your test goal explicit
- Make tests "small and simple" - Use setup and teardown as necessary
- Keep tests idempotent.
- Not cleaning up is not only impolite but can cause errors for other test cases!
- Test only one thing!
- 1 assert per test = easy to understand and simple :)
- Fast tests only!
- Quick tests required as they will be run over and over.
- Absolute repeatability
- Tests ONLY fail if there is a bug in the code under test.
- One pitfall is using Thread.sleep to handle concurrency issues
- Understand what your goal is (draw it out!)
- Use proper concurrency tools to enforce an execution order (e.g. countdown latches)
- Independent tests
- Tests should not rely on other tests or be affected by execution order.
- Provide diagnostic data on failure
- Use messages on assertions and throw sensible exceptions.
- Ensure portability
- Do not hardcode environment details into the test.
- Silence is golden
- Only speak up if the test is broken. Don't pollute the output.
- However, sometimes a little additional output is very helpful for debugging.
Back to WhatToWorkOnForOpenJDK
Back to AdoptOpenJDK