>The problem I've had with doing this sort of TDD, is that I end up with REAMS >of tests at the unit level that make changes to the >codebase expensive. When >you refactor your app, you also have to refactor your tests. The more tests, >the more work to refactor.
I just do not understand this argument. I have never had this problem. It is true - If you change a unit, you have to change the corresponding test - just one test. If you find you have to change multiple 'unit' tests, then a) your tests are NOT unit tests b) it is likely that your code suffers from coupling. The whole point of TDD is that test-driving ruthlessly exposes design problems that make testing hard. Blaming the tests because testing your code is hard is the wrong way round. I find TDD makes my code MORE malleable. thats the whole point. That said, please continue with whatever works for you :) >So the happy medium I've developed, is to push as much code out of my >application as possible, into supporting libraries that are >unit tested at >close to 100% ... What I'm finding is ... the code that I push out to the >libraries is better because I've had more > thoroughly consider how to make it compose well Bingo! Now, why is it necessary to push it out to a library before you can test it properly? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~----------~----~----~----~------~----~------~--~---
