> I'd encourage you to keep practicing test driving your design at the > unit level.
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. To fix it, I need to be actively cleaning up my tests as I develop, in essence writing the tests last, at the end of development of a feature. If I drive it out with an integration test and ignore unit tests for most things, I find the code base is more malleable. But then I don't have very good coverage. 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%, and then only do integration testing of the application. What I'm finding is that I end up with less code to maintain, the code that I push out to the libraries is better because I've had more thoroughly consider how to make it compose well, and all sorts of good vibes from creating building blocks libraries to help us do things better. Maybe this is obvious to everyone else, but I only realised this when I moved to the iPhone, where the tools are bad and testing seems to have a higher burden. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
