Sociable Tests

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:

• Jan Lesner is a passionate software developer and has his own opinion on unit testing
• We discuss isolated and sociable unit tests and their importance
• Jan shares his experience with testing frameworks and handling test data
• The importance of feature tests and how to implement them effectively is emphasized
• Jan speaks out against extensive mocking and prefers testing with real databases
• The role of architecture and design decisions in the testability of software is emphasized
• Jan gives practical tips on how to deal with existing software that was not designed for testing
• The importance of test data generators and how they can simplify the creation of tests is discussed

Isolated vs. sociable unit tests: a breath of fresh air in software testing

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.

What testing really means

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.

Isolated vs. sociable unit tests: a crucial distinction

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.

The role of the developer in the testing process

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.

Practical tips for more effective testing

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.

Mocking: friend or foe?

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.