Taylor Strait wrote:
I've been working through the book 'Beginning Ruby on Rails E-Commerce' which is very heavy on Test Driven Development. As in, you have to write tests for scaffolding methods and validations and crap like that. And then they fail. And you KNOW its the test not the method. So you spend 2x the time writing a test that has to be adapted when requirements change. You really are doubling / tripling your code.
Rails went from fun ActiveRecord magic tricks to a world of 'TEST FAILED.' As a beginning Rails developer it has really taken all the fun out of RoR development. Is TDD so much better than writing methods and testing using a combination of the application interface and Navicat to check the database? Because I hate it.
Rails makes test-first somewhat hard, but still much easier than Brand X. You are lucky to have a book that gets you over the curve - and you just recommended an otherwise boring title to me!
The fall-back is "developer-centric testing" where you alternate writing test cases, writing code, and editing the test cases so they accept the code you wrote. I suspect that's how Rails itself was invented, and it's a big part of the reason why Rails is so powerful.
Tests break when you make big changes. The fix is to not make big changes. Make very small changes and pass all tests. When requirements change, introduce the new requirement one tiny feature at a time. If a test fails, inspect it to see if it prevented you from making a mistake; if not, adjust it to the new requirements.
With even a little automated testing, you will debug much less, and your projects have much more momentum. You can make small edits and run tests with general assurance that things you forgot about did not break.
Without that support, you get debugging and churn, where fixing bugs causes more bugs. Yes, some of us feel nostalgia for the olden days, when the Quest for Bugs made us feel heroic. Get over it.
Under Debugger Driven Development, you start with fun magic tricks, and descend into a nightmare of "app failed!". And you might not even have a clue which module to inspect.
Under TDD, if your program unexpectedly fails, you have an option that debugging can't provide:
-> you can revert your change <-
Treat that like a magic button on your editor called "kill bug". Debugger-driven development simply doesn't provide that simple option.
