|
In my (somewhat limited) experience, there's no such thing as writing code without testing it. The question is: are you testing this manually every time or are you automating it? I think that's a valuable way to phrase it to a non-technical manager, phrase in terms of limited situations: A. I never test my code. When we go to ship the code, it breaks, and I have no idea where it's broken. So now I'm forced to take pieces out to see which piece is broken, then take functionality out of that piece until I find the piece that's broken. This is a process that actually takes longer than writing code, and it prevents me from working on new projects. If this is given to someone else, it will take them twice as long because they don't have the context of how the pieces work, and they'll wind up asking me about it anyways. B. I never write tests for my code. After every piece I write, I test the project in entirety to see if that piece works and does what I want it to do. After the project is done, suppose we want to change that piece. Because there's nothing written that will test these pieces alone, someone now has to do work I've already done, which will keep them from working on something else. C. I write tests before or as I write my code. I know when the pieces I write are done when they pass those tests. It takes around as long to write tests as to write code, so this process is faster. When we want to change a piece later on, we just change the tests to express the new desirable functionality, then rewrite the piece to pass those tests. When I'm troubleshooting my code, I'm not adding value to the product or company. Therefore, the shortest amount of time spent troubleshooting is in turn the most profitable. C is clearly the shortest amount of time, because by writing tests I ideally spend no time troubleshooting. In reality, things will slip through the cracks, but those cracks are a lot smaller. |