Reputation: 6630
I was in an interview and this question was asked, whats the best way to answer this?
I know the lifecycle of TDD is as follows
1- Write the test
2- Run the test (there is no implementation code, test does not pass)
3- Write just enough implementation code to make the test pass
4- Run all tests (tests pass)
5- Refactor
6- Repeat
Lets say I would like to create a software and follow TDD. Where should I design the software? For example, I would like to design a software to enable user registration, enabling them to access their profile and search for the products.
Based on the steps I should write a test lets say for registration, then write a code for it to pass it then try to refactor it, how about design of software? I am a bit confused.
TDD is about making new changes to the software and testing it, how about design?
Lets say I am developing an application which has following features, registration, member profile, access to search feature (only to members) to search for products, second search feature that is accessible by public and members, about us page, contact us page, product payment for both searches.
Should I start thinking about design, after reaching a complete design start writing tests and then implementation code for lets say registration part, then members profile, members search feature, about us, contact us, public search feature and at the end product payment respectively?
Upvotes: 2
Views: 98
Reputation: 31648
You should always think about design. The big design different between the waterfall model and TDD (or any XDD) is waterfall uses "Big Upfront Design" where the complete design is made before any code is written and the final design set in stone.
This caused problems because later requirements changes or additional clarity after development begins that would affect the overall design was very expensive in terms of time and money to change the software.
TDD still has a design upfront, it's just not set in stone. And hopefully since your code is written in TDD style, it is fully tested and well modularized so that any downstream design changes are cheap to make and don't cause ripple effects in other modules.
Part of the Agile Manifesto is YAGNI (you aren't going to need it) which is used to keep the design as simple as needed. If later on it turns out you need a more complicated design, it won't be as expensive to change as it would have been if made via Waterfall.
So to summarize:
Always think about design, before, during and after each step in TDD just don't make it more complicated than it needs to be with what you currently know.
here's a blog article I found that covers this in more detail: http://www.javacodegeeks.com/2014/09/agile-myth-6-agile-means-no-upfront-design.html
Upvotes: 2