This document discusses ways to make test suites run faster. It presents three approaches: being a cheater by using faster machines and parallelizing tests; being lazy by deleting unused tests and code and using in-memory databases and servers; and being brave by breaking long integration tests into smaller pieces, mocking slow layers, and minimizing browser testing. The key message is that there are many simple tricks that can significantly speed up test runs without major refactoring efforts.

1. Let's make this test suite
run faster!

2. David
Gageot
Freelance
developer
@dgageot
javabien.net

3. Why make a test suite run faster?

4. “ I firmly believe it can make your
product beBer. Faster to test leads
to faster to write, deploy and use ”
Anonymous bearded freelance developper

5. You test early and oHen. Right?

6. ConKnuous integraKon?

7. ConKnuous tesKng?

8. ConKnuous deployment?

9. TesKng a lot can lead to waiKng a lot

10. How wants his coding room to look like this

11. Test suite duraKon can be contained

12. Jenkins slaves to the rescue

13. Jenkins slaves to the rescue. not.

14. Why complicated when it can be simple?

15. I’ll share a few easy tricks

16. “ I firmly believe it can make your
product beBer. Faster to test leads
to faster to write, deploy and use ”
Anonymous bearded freelance developper

17. How can we accelerate the tests?
The Cheater
The Lazy
The Brave

18. The Cheater

19. Buy a faster machine. Tests are cpu/memory bound

20. Thank you
Q/A

21. BUT single threaded tests get slower over Kme
100
75
50
25
0
2007 2008 2009 2010

22. Use all the cores with Maven3
mvn -­‐T1 clean install : 5:05s
mvn -­‐T4 clean install : 3:10s
Beware of
tests with side
effects

23. It’s not just me

24. Use all the cores with JUnit/TestNG
Beware of
tests with side
effects

25. That’s it for cheaters
No silver bullet

26. The Lazy

27. Delete useless tests
It’s
so
simple,
we
don’t
do
it...

28. Even beBer, delete dead code

29. Even beBer, delete dead code
Leads
to
dele:ng
even
more
useless
tests

30. Work in a sandbox
The
database
is
slow
In-­‐memory
database
H2
behaves
much
like
MySql
As simple as
changing an
xml file

31. It’s Not only SQL
The
network
is
slow
If
going
for
NoSQL,
choose
a
server
that
can
run
in-­‐process
eg.
Voldemort

32. In-­‐memory SMTP Server
SubEtha
SMTP

33. Abstract the filesystem
Apache
VFS
(Virtual
File
System)
Spring
Resource...

34. In-­‐memory everything
As a bonus, tests will
run smoother

35. Of course all of these are easier to setup
at the beginning of a project

36. The Brave

37. 5 minutes a day can make a difference

38. Don’t test business rules in integraKon tests
Unit
tests
are
oPen
a
beQer
place

39. Not the same scale of speed
10sec
.01sec

40. AcKon #1 -­‐ Break the longer integraKon test
Into
one
faster
integra:on
test
and
a
lot
of
small
unit
tests

41. AcKon #2 -­‐ Mock the slowest layers
eg.
with
Spring
and
Mockito
spies
Mocks are
not just for
unit tests

42. AcKon #3 -­‐ Don’t test through the browser
Selenium
is
oPen
overkill
«But
my
applica:on
is
complex!»
«My
users
want
complex
features,
My
users
want
Ajax»
«I
need
to
test
browser
compa:bility!»

43. Really?

44. Complexity has a cost
That
you
pay
each
:me
tests
run

45. Test through the browser the strict minimal
Unit
test
Javascript

46. AcKon #4 -­‐ SomeKmes be old school
write
(easier
to
test)
server-­‐side
code

47. Thank you
Q/A

48. One more thing™
Ac:on
#0
-­‐
Simplify
and
op:mize
your
code
Tests
will
run
faster
Keep that one
secret...

49. Thank you
Q/A