How did/would you "force" yourself to do TDD rather than TAD? [closed]

Question

I've been trying to jump on the TDD bandwagon for some time now, and it's been going well except for one crucial thing, normally what I end up doing is Test After Development.
I need a mental shift and am wondering how did you force yourself to write tests first?

Answer 1

The mental shift for me was realizing that TDD is about design, not testing. TDD allows you to reason critically about the API of the thing you're constructing. Write the tests first and it's often very clear what API is most convenient and appropriate. Then write your implementation.

Of course you should be writing tests after too (regression tests, integration tests, etc). TDD often produces good design, but not necessarily good testing code.

Answer 2

A big moment came for me with TDD when I read a certain quote (I can't recall where) that the moment of triumph for a test is the moment when the test changes from red to green.

This is probably all stuff you've read before, but unless I start with a failing test, and it becomes a passed test, that's when I reap the huge psychological benefits. It feels good to change from red to green. And if you are consistent with delivering that moment to yourself, it becomes addictive, and then much easier to make yourself do.

But the trick for me was to isolate that moment and revel in it.

Answer 3

Once i started leveraging dependency injection, my classes became smaller and more specialized which allowed me to write simple unit tests to confirm they worked. Given the limited number of tests i knew my class had to pass to work, the goal of my TDD effort became more clear. It was also easier to identify which classes required integration tests due to dependencies on external resources and which classed required unit tests that injected mock/stub/fake objects into the SUT to narrow the focus of my test.