Read on Twitter
So I& #39;ve started writing unit tests as a standard part of my development workflow. I& #39;m still relatively new to it, and I& #39;m only testing parts of my application that I need to be completely solid, but I& #39;m already observing two changes to my process:
1. Taking the extra time to pull things into their own classes, write proper naming, etc so that I can actually test units individually makes sense now, from a time/effort/cost perspective.
2. On the projects where I do unit testing, I& #39;ve caught 100% of regression bugs before they became a production issue. The immediate angry red text feedback incentivizes me to take more care when refactoring/renaming things, so I end up doing a more thorough job of that overall.
Mostly, the thing that got me testing was a paradigm shift, from: "Ugh, you mean I have to write even more code than I& #39;ve already written?"
To: "So I can run one command to execute everything in my program at once? And find errors before users do?"
To: "So I can run one command to execute everything in my program at once? And find errors before users do?"
For the most part, the people/blog posts/etc that evangelize testing seem to focus on the shiny tools, new modules, pretty error pages, cool features to navigate to the bugs, etc.
The real value is: not having to answer the phone at 11pm because some edge case broke in prod.
The real value is: not having to answer the phone at 11pm because some edge case broke in prod.
I think if testing was sold to me like that upfront ("Hey kid, wanna get some sleep at night?") I& #39;d have adopted it years ago.
