I have seen both sides of the coin, and I can assure you TDD is what you should follow. The best approach varies from person to person & company to company and largely depends on the culture, so it will be better if I tell you what we do here @ Unbxd.
Lets say I have to write an application, here is what I would do.
- Design, Design, Design (On Paper)
- A generic flow is created after understanding a particular problem statement/requirement (On Paper)
- Jot down all possible failure cases (On Paper or some notepad)
- Jot down all possible success cases (On paper or some notepad), mind you failure cases should be way more than success cases, else you are doing it wrong
- Segment the flow you created in step 2, and create a class structure based on it. Think of all the places where the classes can actually be pluggable, i.e. you can have interfaces.
For instance, if the application is getting data from a data source the IndexReader.get() should be an interface, and real implementation should vary. This is important because this is the best place to plug your tests.
- Write interfaces.
- Write test cases which you wrote down in paper as actual test cases for these interfaces.
- Once that is done, write remainder of your code.
What happens with such an approach is you have a better clarity on what you plan to write and the code is bug free.
have you found it to be effecting the design of your code in any way?
Yes, you start thinking much more clearly. As I mentioned, you will have to identify various points which can be made pluggable, then there is an added advantage of you not writing anything until everything is clear to you. 90% of the bugs are caused by incoherent ideas and bad design.