Software Craftsmanship

Software Craftsmanship

The case for writing (isolated) test cases #3

Divide and Conquer Since three out of four small businesses fail, my recommendation is to start a large business. Legacy Code and SOTA "Legacy code" is often used to characterize old software systems inflicted with a crucial maintenance debt that accumulated for years. But legacy code can happen very soon in a project. The best intentions, plus a misaligned or degrading SOTA (State Of The Art) can change your greenfield project into a legacy code factory in a matter of 3 to 6 months, before…

Lire la suite
Software Craftsmanship

Le refactoring c’est tout le temps, et c’est normal. (épisode 3 – appel à un ami)

Trop de doutes, Charlotte a besoin de conseils. Marc est indépendant, il est très fort techniquement et très gentil, ça va bien se passer c’est sûr. Elle a toute confiance.  « Marc mon ami, tu pourrais me faire une revue de code ? « J’ai beaucoup avancé et j’ai besoin de tes feedbacks pour continuer.  « Je me pose quelques questions sur des endroits bien précis, mais le mieux je pense c’est que je te laisse regarder. — D’accord, pas de soucis, je regarde ça.…

Lire la suite
Software Craftsmanship

The case for writing (isolated) test cases – #2

What is legacy code? "Code without tests is bad code. It doesn't matter how well written it is; it doesn't matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don't know if our code is getting better or worse.” “To me, legacy code is simply code without tests.” Michael Feathers, Working Effectively with Legacy Code "The code has no tests." Such a report often strikes me as a…

Lire la suite
Software Craftsmanship

The case for writing (isolated) test cases – #1

Should we write unit tests or integration tests ? "There is hardly anything in the world that someone cannot make a little worse and sell a little cheaper, and the people who consider price alone are that person’s lawful prey. It’s unwise to pay too much, but it’s worse to pay too little. When you pay too much, you lose a little money — that is all. When you pay too little, you sometimes lose everything, because the thing you bought was incapable of doing…

Lire la suite
Software Craftsmanship

Hexagonal Architecture: three principles and an implementation example

Documented in 2005 by Alistair Cockburn, Hexagonal Architecture is a software architecture that has many advantages and has seen renewed interest since 2015. The original intent of Hexagonal Architecture is: Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases. To explore the benefits of piloting an application by automated tests, or developing and testing in isolation from the database, we recommend that you read…

Lire la suite
Software Craftsmanship

The Test Pyramid in Practice 5/5

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.

Lire la suite
Software Craftsmanship

The Test Pyramid in Practice 4/5

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,…

Lire la suite
Software Craftsmanship

The Test Pyramid In Practice (3/5)

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.

Lire la suite
Software Craftsmanship

The Test Pyramid In Practice 2/5

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…

Lire la suite
Software Craftsmanship

The Test Pyramid In Practice (1/5)

 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.…

Lire la suite