Technical Notebooks on Java Development

Test Doubles are replacements of inconvenient dependencies. When properly used, they help to keep your tests focused, fast, readable and stable. They also come with risks like increased test setup complexity, increased coupling to implementation details or even partial replacement of the actual functionality under test. For a positive impact on the test suite, make sure your team has guidelines on when and how to use test doubles. Test doubles are usually introduced when the dependency is: Unpredictable: real database, current time Unavailable: web service Slow: real database, web service Asynchronous: message brokers, mail servers Expensive to use: setting up browsers, web services Has no test version: third-party service Lives in another application layer: layered architecture Internal, even in the same layer, but we want to write Solitary Unit Tests Types of test doubles demonstrated by the sample project in this post are: Dummy = Irrelevant arguments Stub = Fi

You want the internal structure of the code inside a component to keep its shape during development. The chosen development approach, like Domain Driven Design , gives you design guidelines for shaping the component, including dependency rules (E.g. domain model to not depend on infrastructure). Bigger the project, harder is to catch package dependency violations using standard practices like code reviews. At a higher level, the dependencies between components are easier to control. For example, you can rely on Maven dependencies which means problems are caught at compile time. But inside a component, even if you go smaller - with one microservice per bounded context, non-trivial domains will contain a considerable number of classes and packages. The solution is to implement a quality gateway for this architectural aspect, aka defining a Fitness Function according to the book Building Evolutionary Architectures . The book contains examples with JDepend  but I found it very hard to