When you start the code by writing the general flow as steps and making each step a function, you're actually making a contract (probably with your future self): I'm saying this function does this and this is what it does.

We all know writing the damn docs for functions and classes and modules is a pain in the backside. But realizing what you were thinking when you wrote the function will save your butt in the future.

When developers try to solve a problem, they sometimes try to find a way that will solve all the problems, including the ones that may appear in the future.

If you write a test for every single function on your system, and your system keeps changing, how will you know when a function is not necessary anymore?

You can be sure that if a language brings a testing framework -- even minimal -- in its standard library, the ecosystem around it will have better tests than a language that doesn't carry a testing framework, no matter how good the external testing frameworks for the language are.

There is one magical thing you need to know when reading this book: It's all personal opinion

Gherkin is file format for writing behaviour tests (BDD). But it can also give you some insights on what you should do.

The view of the whole is greater than the sum of its parts. And that includes tests for the whole compared to tests of single things.

Testing things in isolation may give a better view of your APIs.

You know that "Play" with a little something on your IDE that runs only the tests? Do you know what it does?