The hardest test to write
I like writing tests, because they prove the code will run like I expect. I like it even more when I can write tests before I write code. But often I can’t do that, because I'm still figuring out how the code will work. To put it another way, I'm not sure where I'm going, so how can I ask for directions?
Another challenge is when there is already some code in place that was not written with tests in mind. The code is written like a black box, giving out no secrets, taking no prisoners or arguments. That's why tests should be written first.
Sometimes, I convince myself that it's quicker to do manual tests by refreshing the browser or repeating the commands in the terminal. Then I realise that I'm making slower progress, because automated tests are much faster and less error prone than manual tests.
Setting up tests is a one-off toll to get on the highway.
Eventually, I find my way. Either the path becomes clear and I know what I'm aiming for, or I'm tired of repeating the same actions over and over - code, run, check, code, run, check. And I commit to writing the first test.
Code, check, repeat.