Because in my view the main purpose of tests is to check the expected behaviour of the program, and the most direct and clearest way to do this is to verify that the program returns expected outputs for the given inputs.

This is definitely a big and an important reason. After a few decades of programming I’m absolutely convinced that:

1. The problem domain is going to change significantly over the course of the project
2. Our initial understanding of the domain is going to be overly naive. It takes time for our understanding of the domain to properly grow in our minds.

Refactoring is a practice which helps us addressing these challenges, making it possible to shift the internals of the code to match our view of the world and the ever changing requirements. If refactoring is not practiced, the code will rot. Well, either that, or we were somehow able to get the design right in the initial attempt. The latter is IMO less likely to happen than winning a lottery, but even if we are such lucky, the design will likely be overly complex for a better part of the project’s lifetime (see Fowler’s Yagni and Is Design Dead?).

Therefore, any practice which significantly affects the ability to refactor is IMO a very questionable practice.

Classicist testing has some shortcomings, and I agree that isolated tests have some interesting advantages such as the ones you mention here.

That said, when I look at the pros together with the cons, I believe that isolated tests suffer from some significant issues:

1. Tests are less clear
2. They give us less confidence
3. By making refactoring more difficult, isolated tests restrain the evolution of the code design, thus effectively nullifying one of their advertised benefits of assisting with better design.

I also recommend watching this excellent talk on the topic.

Fowler is a classicist, and admits as much in the article.

There are a number of articles you can read out there, I personally like this one (I may be biased):

• London school TDD · testdouble/contributing-tests Wiki · GitHub

quick quote:

Many comparisons between the two schools of thinking can be summarized as “top-down” versus “bottom-up”. Where London-school TDD encourages programmers to use external constraints as a starting point (an API endpoint, an HTTP controller, etc.), Detroit-school TDD encourages programmers to first identify the core domain logic that exemplifies the work without concern for how it might be integrated elsewhere.

For completeness sake:

• https://softwareengineering.stackexchange.com/questions/123627/what-are-the-london-and-chicago-schools-of-tdd
• https://medium.com/@adrianbooth/test-driven-development-wars-detroit-vs-london-classicist-vs-mockist-9956c78ae95f

While I personally like the starting point of the Detroit school (your start with the Domain problem, not the externalities) I use the London school to design tests.

A very good video about London TDD in Elixir can be seen here:

• A practical example of TDD Outside-in with Elixir

Hi ,

Probably you should try to give a look at Growing Object-Oriented Software, guided by Tests - Steve Freeman, Nat Pryce (aka GOOS). It is also mentioned in the video description, along with other resources and examples.

I see that book as the subsequent step for Test-Driven Development: by Example - Kent Beck.

The GOOS book will introduce you to the world of Test-Double, Mock Objects, how the End-to-End testing fit in the development life cycle of an application, the concept of roles discovery, how to improve the test readability and more advises on how to deal with complex test cases (such as asynchronous code and threads). Starting from the Chapter 3, the authors will drive you with a worked example, by building an auction system using all these techniques.

If you are interested on all these topics, I would recommend you to join the Software Crafters Community on Slack.