I think test cases were designed specifically to give me a headache. This chatbot program I'm developing is going pretty well. I always take it as a good sign that my Ruby studies are progressing when I get a headache afterwards. Or during. Whatever!
Either way, it feels good to be building something that functions. Even though that functionality is limited. Even though the code for that functionality was handed to me. I'm glad the source code was available to download, because after throwing multiple errors I found out I had an extra | in my source code. And I was missing a parenthesis before that. What a slob!
Here's a question: what's the advantage of writing test code rather than simply running the source code and checking for errors that way? My guess is by writing a test code, Ruby is checking that the underlying logic makes sense and works, but if that's the case, wouldn't simply running the source code do the same thing? Is it faster to run tests? More economical for larger programs?
I get the feeling writing test code doesn't make much sense to me now, but it's something more vital for bigger projects where more things can go horribly awry.
Writing test code is slow and can be painful, but it is significantly faster than testing by hand when you multiple the number of times you would want to test functionality by the time it takes to do it by hand.
ReplyDeleteLarger apps, with multiple developers or small amounts of development inactivity are drastically sped up by tests. Want to know if you broke something? run the tests. Don't know how the whole app works, but need to make a small change? run the tests and be sure.
Our longest test suites take about 7 minutes to run, and they move far, far faster than a human could. Setting up complex pre-conditions and checking complex final states. I estimate it would take at minimum 8 hours to test that code by hand. I run this thing at least 2-3 times per hour. It's clear that tests make working on this codebase an order of magnitude faster.