The document argues that unit test scopes should be larger rather than having many small unit test classes. Larger unit tests are better because they are less tightly coupled to code structure, can be more easily mapped to business requirements, and test interactions between classes rather than just individual classes. The document provides suggestions for how to structure unit tests at a bigger scope, such as using dependency injection frameworks, test data builders, and splitting tests across multiple classes when there are too many assertions. The overall message is that test scopes should be large enough to cover layers, external libraries, and controllers when possible rather than focusing exclusively on small individual classes.
OpenChain @ LF Japan Executive Briefing - May 2024
Bigger Unit Test Are Better
1. Bigger Unit Test Are Better
why having many small unit test classes will slow you down
2. %: whoami
• Peter Schuler
• Java developer @ Rabobank @ Tribe Wonen
• Trainer and coach
• Writing code since 1992
• Java since 1998
• Interests: Clean code, TDD, Code quality, Security, Architecture,
Gardening
• Lives in the Netherlands / married / three daughters / three dogs
3. %: whoami
• Peter Schuler
• Java developer / Architect @ Rabobank
• Trainer and coach
• Writing code since 1992
• Java since 1998
• Interests: Clean code, TDD, Code quality, Security, Architecture,
Gardening
• Lives in the Netherlands / married / three daughters / three dogs
I am also 2,04 meters. J
4. Agenda
• What do I mean with bigger?
• Why do we write unit tests?
• Why should they be bigger?
• How do you make them bigger?
• How big is big enough?
5. Unit test should have a bigger test scope
So we go from this:
Class
Unit Test
Unit Test Class
Class
Class
Class
To this:
6. Why unit test?
You tell me!
Join the word could:
livecloud.online/join/U446
7. Why unit test?
I was forced to by some ‘senior’ developer
Apparently we need coverage
If I don’t the build won’t pass
Is my code working?
Is my code STILL working?
Will this change affect other parts of the code?
Dare I make this change to the code?
Do I trust my code?
Do I trust code?
9. SubElement1MapperTest
The problem with being small
Response mapper
Sub Element 1 mapper
Sub Element 2 mapper
Enum 2 mapper
ResponseMapperTest
SubElement2MapperTest
Enum2MapperTest
10. The problem with being small
• Tightly coupled to the coding structure eg:
• When your code structure changes, your test structure will change
• This will make refactoring a hell
• So ..when you need them the most
…. small tests will actually work against you.
• The test cannot be translated to business concepts.
• You test classes … but not their interaction …
11. Let’s look at small scoped tests
• Especially classes at both ends of the hierarchy look silly.
• Can you discuss these tests with the business?
• Can you map them on a functional requirement?
13. Let’s do a little though experiment
• Let’s assume that these are
classes / components.
• How will we test that they do as
designed using mocks?
• Shoot!
15. Bigger scope is better
High level interface / service /
rest controller / sub-part
Sub Element 1 mapper
Sub Element 2 mapper
Enum 2 mapper
Unit Test
DAO
DB
TestDataGenerators
Test Infa Setup
MatcherHelpers
External JAR
16. Let’s look at bigger scoped tests
• So now we have tests that we can explain to the business.
• Let’s look at how to make them.
17. Hurdles when being bigger scoped
• They need more “plumbing code” to get set up.
• They need more asserts and more setup.
• Testing every small aspect might be to hard.
• They fail when the business requirements change.
Wait… that is actually a good thing!
18. Couple test to behaviour not stucture
https://www.facebook.com/notes/kent-beck/unit-tests/1726369154062608/
https://youtube.com/playlist?list=PLlmVY7qtgT_lkbrk9iZNizp978mVzpBKl
19. How to make them bigger - Plumbing
• Use Spring..
20. How to make them bigger - Plumbing
• Or just be your own dependency injection framework:
• Or perhaps use Google Guice
• But when you are using Spring, Spring will mostly do just fine.
21. How to make them bigger – Test Data
• Use TestBuilders to build Bigger Object Quicker
22. How to make them bigger – Test Data
• Chain test builders for better semantics. Go to town..
• Grow your own specific test semantics / DSL.
aRequest()
.with()
.twoApplications()
.existingMortgages()
.add(anAnuity())
.add(new CreditMortgageBuilder()
.setSaldo(20000)
.setLimit(40000))
.newHouse(450000)
.currentHouse(200000)
.build();
23. How to make them bigger – Asserts
• Bigger scope means more asserts.
• This drawback is harder to mitigate.
• Solutions:
• Apply clean code standards.
• Test only the small aspects of your who set.
• Make helper functions and delegate
• Split up your tests in multiple test classes for different aspects.
• I once split a calculation test class in positive, negative and weird cases.
24. How to make them bigger – Test all
• Bigger scope makes testing every possible mutation harder.
• Solution:
• Do not test everything BIG.
• It is still fine to write specific tests for specific classes.
• But please try to test against stable interfaces.
• And you can still test small aspects with a big test
25. Be Big and Small at the same time
• You can still be Big, but test a small aspect of your code.
• This also helps with having too many asserts.
26. How big should a unit test scope be?
• In scope:
• Everything that is a “pure function”
• Layers in your application.
• External JAR files
• Controllers
• DB’s -> can be unit tested easily these days.
• Out of scope:
• External network calls.
• But this is all a guideline … you are in control of your own fate J
27. What I want you to do
• Make your test scope bigger.
• Stop excessive mocking!
• Base your unit test on business data.
• But … do not ..
• … stop writing tests
• … stop feeling free to test small
• … only think big.
