Does an isolated small unit test really do us any good? There are many ways to automate testing, and sometimes you have to deviate from theory to maintain quality. Tools like Cypress, Selenium, etc. can be challenging for developers. This is where the GBT (Guided By Tests) approach offers advantages. Jan thinks consistently in the direction: What is the developer’s job and provokes with his statement “Throw away mocking!” - for good reason.
“Martin Fowler (…) talks about the fact that the developers are responsible for what we call unit tests. And that we have a distinction there, one is what he calls ‘isolated unit tests’ and the other is what he calls ‘sociable unit tests’” - Jan Leßner
Jan Leßner is a software developer, architect and systems analyst at S&N Invent. He is a book author and Java programmer from the very beginning and is involved in various open source frameworks. For over 10 years he has been involved in enterprise projects with a focus on balance sheet analysis, loyalty programs and telecommunications. There he is not only involved in the actual development, but also in the development of elegant software engineering.
Highlights of this episode:
In this episode, I talk to Jan Leßner about the importance of tests in software development, in particular the difference between isolated and sociable unit tests, as well as the challenges and strategies for improving testability in projects.
In this podcast episode, I had the pleasure of speaking with Jan Leßner, a passionate software developer and expert in the field of testing. Jan’s views are quite provocative and offer a fresh look at what testing really means and how it can enrich the development process.
Perhaps you are now asking yourself: What exactly distinguishes isolated from sociable unit tests? According to Jan, this distinction is fundamental to understanding modern testing strategies. Isolated tests focus on individual components without considering their interactions, while sociable tests look at larger units - especially use cases or features. This perspective calls for a paradigm shift: away from focusing solely on the smallest units and towards looking at how these units work together to create a functioning whole.
Another key topic of our discussion was the role of the developer in the testing process. Developers are not only responsible for the code itself, but must also ensure that the application works as a whole. This includes the development of sociable unit tests to ensure that all components interact correctly with each other. This often requires a bold step away from traditional methods towards innovative approaches that can speed up the entire development process.
Jan shared some valuable insights on how to make the testing process more efficient. One key aspect is the use of headless end-to-end testing. This method eliminates the need for complex UI testing and allows developers to test features comprehensively - from the user interface to the database. We also talked about the importance of good project architecture and design decisions that consider testability from the start.
One particularly interesting discussion revolved around the topic of mocking. While mocking is often seen as a useful tool, Jan argued that it should be avoided as much as possible. Instead, one should focus on realistic test environments and only mock external systems where it is absolutely necessary. This leads to more meaningful tests and at the same time reduces the effort required to create and maintain mocks.