Let’s make this test suite run faster, David Gageot, @dgageot
Continuous testing: infinitest
run test automatically in the IDE when you make changes
Cheaters:
build up to 4 modules in parallel
mvn -T4 clean install
but careful with tests with side effects!
surefire plugin : run tests in parallel
but careful with tests with side effects!
Lazy:
delete useless tests
delete dead code (and remove the tests for that code)
use statistics to figure out which features are not used
work in a sandbox
– database is slow (e.g. use in memory H2 which is very similar MySQL)
– NoSQL: choose a server that runs in memory, eg Voldemort
– SMTP server: eg SubEtha SMTP
– file system: eg Apache VFS, Spring resource
do everything in memory, as a bonus it is easier to parallelize tests
Brave:
5 minutes a day can make a difference
don’t test business rules in integration tests – do it in unit tests
Break longer integration test into a faster integration test and small unit tests
Mock the slowest layers, e.g. with Spring and Mockito spies
– in post processor, wrap beans with a spy
Don’t test through the browser, Selenium is often overkill
Action #0 Simplify and optimize your code
Part II : preferred testing techniques
————————————–
MoreUnit eclipse plugin to switch between class and test
CTRL-Shift-T in Intellij to move to test
infinitest (both eclipse and IntelliJ)
automatically run tests which are impacted by a code change
junit max
like infinitest but runs all tests, sorts tests (failing most and faster tests first)
hamcrest to build more readable assertions
assertThat(“hello world”, is(equalsTo(Greeter.greating)));
FEST-assert to build even more readable assertions (better than hamcrest)
assertThat(yoda).isInstanceOf(Jedi.class)
.isEqualTo(foundJedi);
http://fest.easytesting.org/
JUnit 4.10
@Theory, @DataPoint (nightmare)
@Rule : applied to all tests in class, can be changed during the test (in code)
@SuiteClasses
@Category (beta)
Leave a Reply