Ask anyone who plays games, it is addicting to accomplish small goals.
Dopamine causes extreme pleasure and is associated with reward-seeking behaviors.
Establish a self-reward system by increasing your sense of responsibility (but not overwhelmingly) for achieving certain goals so that when you achieve them you will feel a greater sense of accomplishment.
Launch a series of smaller achievable goals en route to the bigger one. See the attainment of each smaller goal as a significant rung on the ladder toward achieving the largest one.
Increase the value you place on certain goals by seeing the pleasure they can bring to you and others.
The payoff of these tests won't be felt for months or even years. When it comes time to change the code, you can do it with more confidence.
We like to start by writing a test as if its implementation already exists, and then filling in whatever is needed to make it work — what Abelson and Sussman call "programming by wishful thinking". Working backwards from the test helps us focus on what we want the system to do, instead of getting caught up in the complexity of how we will make it work.
We decide to push on and see where the code takes us.
We define a null implementation as a temporary empty implementation, introduced to allow the programmer to make progress by deferring effort and intended to be replaced.
Nothing shakes out a design like trying to implement it.
Once we'd broken through our inadequacies as programmers, the tests became much clearer.
Although we rely on our experience to guide our decisions, we reached this solution almost automatically by just following the code and taking care to keep it clean.
We need to apply as much care and attention to the tests as we do to the production code.
Think of one coherent feature per test, which might be represented by up to a handful of assertions.
The point of a test is not to pass but to fail.
We try to follow the four-step TDD cycle (fail, report, pass, refactor).
To try out TDD for yourself, try my Bowling game kata.