You are right, it is very hard to change the way to work, even worst, after years of using TDD, at least me, somehow I still have the bias of thinking that jumping to the code is faster.

But it isn't.

The problem of learning TDD is that it is hard. The hardest part is to write the test. Not because the code is difficult, which is a challenge by itself, but because it is difficult to decide what to test and at which level.

Something that I have discovered, is that BDD helps a lot on that. Because it helps to focus on the business level, and you can choose at any moment the "unit level". By the way, the unit level should be always the greater possible, the less implementation details you test the better (focus only on business rules).

A rule of thumb that I discovered some years ago, is the one that I wrote in my first medium article:

> Start writing tests as they were documentation

And thanks for sharing!