Publications de Lyman GILLISPIE

In prior articles (1, 2, 3, 4), we’ve implemented isolated tests which offer us precise and reliable feedback - and are more or less fast depending on whether we’re running unit tests or component tests which need to load a Spring context. But these tests have their limits, precisely because they’re isolated. In this article we’ll deal with tests that are even higher in the pyramid: integration and end-to-end tests. This article originally appeared on our French Language Blog on 29/06/2018.

In the last article we described component tests: tests which are half unit and half integration test, that allow us to validate both integration within our application (via dependency injection) and also with peripheral components. All of which while remaining sufficiently isolated, to limit friction during execution. Because this isolation works perfectly, our API client tests suffer from a major flaw: if and when the supplier changes the service signature we learn about it much too late. This is what contract tests attempt to avoid,…

The previous article detailed the base of the pyramid: unit tests and their role in preventing regressions in our application. But they’re far from being sufficient, and we need to use other types of tests. In this article, we’ll cover component tests. This article originally appeared on our French Language Blog on 27/06/2018.

In the previous article, we discussed the theory of the Testing Pyramid -- a testing strategy to ensure our application’s quality at a reasonable cost. Notable, we discussed the notion of feedback, and the importance of having fast, accurate, and reliable feedback. Unit tests typically address these criteria for a modest investment. Through this article we’ll develop a concrete example to explore the use of automated unit tests and try to answer some of our readers’ recurring questions. This article originally appeared on our French…

 If you read this blog or our publications, you know how much testing is tied to software quality and, if I may say so, to software success. I insist on this point because all too often our customers treat tests as the fifth wheel when it comes to development. You know the consequences: an astronomical number of design anomalies, pernicious bugs in production and, worse still, software which ossifies little by little. This article is the first in a series, and will mostly address theory.…