Tests
A separate series for juniors: what tests are and what a project expects of you, how to read a red build, which cases to test, how to tell whether a test checks anything at all, how to replace neighbors, and how to test code together with a real database.
It stands on its own: you don't need the "Articles" section for it. If a topic is covered there, the article tells you where. Read in order: each article is the next step.
Published 7 of 7
"From Red to Green" 1–7
From the first test to a test with a real database. The running example is a deadline check; the main idea: trust a green test only if you have seen it red.
-
1Why tests, and what the project expects from you
Why tests matter and what a project expects from a junior: a test versus checking by eye, JUnit and AssertJ, Maven and Surefire, the test pyramid.
30 min read
-
2Your first unit test: from an empty file to a green report
A first unit test with JUnit 6 and AssertJ from scratch: the class, the method, given-when-then, the name, and making sure each test can go red.
25 min read
-
3The test went red: what to do
A red report: the message, the stack trace and report files, turning a bug into a red test, and "green on my machine, red in the build."
30 min read
-
4Which cases to test
Which cases to test: input classes and boundaries, a table of cases, one parameterized test, errors, an empty list, and null.
30 min read
-
5A test that checks nothing
A test that can't go red: how to fix it, what JaCoCo coverage shows and what it hides, and checking tests by breaking the code.
30 min read
-
6When your code is surrounded by other code
Stubs by hand and with Mockito: replacing the database, another service, and the clock, and what not to replace.
30 min read
-
7A test with a real database
What only a real database catches: Postgres in Docker via Testcontainers and Flyway, and one shared test database where tests don't break each other.
30 min read