Unfortunately, it stays hard no matter how much deliberate practice you sink into it. I didn't understand what DHH was saying about design damage inflicted by testing until I started seriously confronting questions like "which parts of this API should I mock and which parts should I just use integration tests for?"
Eventually you spend more time thinking about testing than you do actually getting shit done. You have to because otherwise you find yourself rewriting tests every time you refactor. You rationalize this time under the guise of "it's making me think more clearly about my design." Once it starts wearing thin disillusionment takes root. The first step towards my own enlightenment was when I realized that I needed tests to help me ensure that my test framework was working. What's testing those tests? Tests are code, and code needs to be tested. Where does it end?
I wrote my own toy test framework as an exercise. I was trying to * really * wrap my head around meta-programming, so I meta-programmed my test suite to test the heavily meta-programmed data classes. It solidified into a grotesque mush and I scrapped the whole thing. Now I'm solving the original problem with boring old Rails and sanity has been restored.
Now when I start a project I do it knowing that my code is going to suck and I'm going to refactor it over time. The truth is, when there's no tests I only have to refactor one code base and not two. I don't need to learn two frameworks. I don't need to understand two domains. The amount of time I've spent maintaining code has sharply diminished after I stopped being so religious about testing. If I don't know what it's doing, the REPL is my best friend. Backtraces rule.
If your code is Serious Business, like, say, SQLite which is used everywhere, a robust test suite is a very nice tool to have and maintain. For everyone else, it's another step on the road to mastery.
Also if you're using a dangerously unsafe language like C, tests can alert you to brewing problems. If you're using a safe language solving not-so-hard problems, a test framework is just adding complexity to paper over your lack of experience.
Eventually you spend more time thinking about testing than you do actually getting shit done. You have to because otherwise you find yourself rewriting tests every time you refactor. You rationalize this time under the guise of "it's making me think more clearly about my design." Once it starts wearing thin disillusionment takes root. The first step towards my own enlightenment was when I realized that I needed tests to help me ensure that my test framework was working. What's testing those tests? Tests are code, and code needs to be tested. Where does it end?
I wrote my own toy test framework as an exercise. I was trying to * really * wrap my head around meta-programming, so I meta-programmed my test suite to test the heavily meta-programmed data classes. It solidified into a grotesque mush and I scrapped the whole thing. Now I'm solving the original problem with boring old Rails and sanity has been restored.
Now when I start a project I do it knowing that my code is going to suck and I'm going to refactor it over time. The truth is, when there's no tests I only have to refactor one code base and not two. I don't need to learn two frameworks. I don't need to understand two domains. The amount of time I've spent maintaining code has sharply diminished after I stopped being so religious about testing. If I don't know what it's doing, the REPL is my best friend. Backtraces rule.
If your code is Serious Business, like, say, SQLite which is used everywhere, a robust test suite is a very nice tool to have and maintain. For everyone else, it's another step on the road to mastery.
Also if you're using a dangerously unsafe language like C, tests can alert you to brewing problems. If you're using a safe language solving not-so-hard problems, a test framework is just adding complexity to paper over your lack of experience.