Catalogue Browser

Lazily evaluated attributes and values are only computed when they are needed.

In tests, some components are good candidates for being lazily evaluated, i.e., SUT dependencies and assertions.

For instance, assertions' message of failure that are expensive to compute may benefit from lazy evaluation.

Test cases with many assertions are known as the assertion roulette test smell.

One way to fix it is replacing all assertions that have the same actual value with one single Fluent Assertion.

Fluent Assertions enables chaining together different condition checks as unary method invocations.

Test Methods with multiple assertions may have its execution interrupted prematurely.

Grouping multiple assertions with JUnit 5's assertAll assures that they execute and their result are outputted before terminating.

Having a conditional logic in the assertions using the not (!) operator affect their readability.

Forced conditional expressions into assertTrue/assertFalse methods to verify objects equality should be replaced.

Developers should use special assertions (e.g. assertNull) instead of passing reserved words.

Change Return Type and Add Parameter refactorings in production APIs are mainly responsible for breaking tests.

JVM applies type inference to detect automatically the datatype, making tests more resilient.

Complex test data creation can be alleviated in different ways.

AutoFixture works as a generic Test Data Builder.

ObjectMother encapsulates complex build logic into static methods for reuse.

Preconditions determine whether it makes sense to continue execution.

Placing preconditions in a class-level fixture is useful for efficiency.

Conditional Execution (JUnit 5) enables test skipping according to programmatic conditions.

Test methods within a single test class may evolve and share many code similarities.

It is advisable to place the duplicated code into a test fixture (setUp or tearDown).

As new methods are added and others removed, test fixtures may become obsolete (General Fixture smell).

One may inline the test fixture, introducing code duplication into the few test methods that still depend on it to improve independence.

Diverging context of test methods leads to General Fixture.

Minimizing fixtures make tests better suitable as documentation and less sensitive to changes.

Testers extract subclasses that override test fixtures to reuse tests under different environments.

Note: JUnit 5 requires specific annotations on overriding methods unlike JUnit 4.

Complex SUT dependencies are good mocking candidates.

Injecting such dependencies into the SUT constructor often enables evaluation of interaction with mocked dependency.

The components defined in a test fixture should not be modified during the test execution unless the test fixture runs once per test method.

Sometimes a test fixture does not have to execute once for each test method.

Constraining execution to once for all methods can speed-up test execution.

Split the time-consuming part of a fixture (which goes into setupClass) from the part that requires execution before each test (which goes into setup).

Merge separate fixture methods to simplify setup logic when separation is unnecessary.

When multiple methods only differ in terms of data input, it is a good candidate for parameterization.

JUnit 5’s and TestNG’s parameterized tests allow data providers to improve cohesion.

When test cases differ in the Arrange phase (setup), developers may choose to parameterize their fixture or utility methods.

Developers leverage method and superclass extractions to achieve the same behaviour.

Good assertions' error messages are useful for debugging.

Test frameworks rely on method names to identify tests; parameterized tests benefit from custom names.

Avoid Assertion Roulette by adding explanations.

Breaking integration tests into unit tests consists in promoting isolation through mocking.

Ensures robust coverage of isolated behaviours while balancing risk mitigation with quick feedback.

When a test repeatedly evaluates the same assertion for a fixed number of times, the code can be simplified with @RepeatedTest.

Oftentimes, unit tests simply differ to integration test due to mocked dependencies.

Generalize test code so real instances and mocks can be used interchangeably.

Parameterized tests with many parameters may become hard to read.

Introducing parameter objects encapsulates all parameters into one object.

Standardize a complex MUT invocation.

Combines many assertion invocations into a custom higher-level assertion method.

Encapsulates environment configuration and clean up.

Test suites may have test methods with common features (execution time, code size).

Developers may want to execute those groups separately and in a specific order.

Utility methods can be extracted and collected into a General Utility Class.

Using named Expectations in JMockit allows setting up custom shared mocks in a base class.

Test methods may evolve and accumulate multiple responsibilities (Eager Test).

Test methods can be separated in multiple pure test methods to improve the execution trace for debugging.

Test suites can accumulate redundancies over time.

When such redundancy is scattered throughout multiple test methods, we can eliminate code duplication by merging them.

TestNG's Groups, JUnit 4's Category, and JUnit 5's Tags are equivalent features but differ in flexibility.

Tags (JUnit 5) integrate with other features such as custom display name.

Migrating tests with custom runners may require adapting JUnit 4’s Runner API to JUnit 5’s Extension API.

Ease of use and active development are reasons to migrate to Mockito.

Powermock includes support for mocking static methods where earlier frameworks might not.

Updates annotations from JUnit 4 style (@Before, @BeforeClass) to JUnit 5 style (@BeforeEach, @BeforeAll).

Adopted test library may lack desired features (fluent API).

AssertJ is a fluent assertions library compatible with most test frameworks.

JUnit 5 introduces new assertions like assertThrows.

JUnit 5 supports parameterization by default, allows multiple argument providers, and includes over ten provider types (CSV, Method, etc).

Using try-catch or @Test(expected=...) enables false positives.

JUnit 5's assertThrows preserves execution of remaining statements and targets specific calls.

TestNG’s @Test annotation can be used on classes. Migration often involves switching scope.

JUnit 5 provides a separate annotation (@Timeout) rather than a parameter on @Test.

When a test repeatedly evaluates the same assertion for a fixed number of times, it can be simplified.

Testing permutation of values with nested loops should be parameterized.

Using external resources (files) is a symptom of Mystery Guest.

Using @TempDir ensures resources are created and cleaned up automatically.

Running test cases concurrently is challenging when relying on shared resources.

Using @ResourceLock synchronizes resource acquisition.

Tests that use external resources are not self-contained.

Incorporate the resource content into the test code to remove dependency.

Optimistic assumptions about external resources cause non-deterministic behavior.

Explicitly create and release resources before/after testing.

Overlapping resource names cause crashes in concurrent runs.

Use unique identifiers (e.g., timestamps) for allocated resources.

Test methods with multiple assertions on object properties are hard to debug.

Compare objects with an expected object (equals method) rather than properties separately.

Testing software relying on clock time is challenging.

Mock the time to speed-up tests and avoid synchronization problems.

Mocks might behave differently than real objects.

Simpler dependencies may not benefit from mocking.

Replacing mock with real instance can be beneficial if performance is satisfactory.

Mocks are efficient and isolate components.

Useful to prevent undesired access to databases and external APIs.

When specific features are heavily used, many tests require mocking it.

Extract a Fake or Stub class used across many tests.

Inheritance requires manually crafting tracking logic.

Mocking APIs provide verification mechanisms out of the box.

Java's anonymous classes are commonly used for creating stubs.

Wrapping them with Spies can be redundant; manual implementation may be simpler.

Switching between Dummy, Stub, Fake, Spy, and Mock based on needs (flexibility vs simplicity).

E.g., replacing a Stub with a Mock for verification capabilities.

Centralize complex mock creation logic.

Object Mother provides specific versions of complex type instances.

Generalize utility methods' return types/parameters to promote reuse.

Export utility classes to share logic among projects.

Reuse cached Spring contexts to avoid initialization overhead.

Use JUnit 4 rules or subclass existing runners to customize behavior.

Useful when only one runner is allowed per class.

Custom annotations tag tests for integration or attach metadata.

Composes multiple annotations (Tag, Timeout, Test) into one.

Nested test classes organize tests into logical groups with scoped fixtures.

Moving test methods reflects changes in production code structure.

JUnit 5 extension model prioritizes composition.

ArchUnit allows teams to define architectural rules in Java.