Like all things related to software development, it depends. If there are many defined edge cases specified in the design spec then TDD is an efficient method to develop software. When the software is being prototyped for the first time; however, it is faster for the team to build the features, demo, and UX test first as user acceptance always results in more UI changes.
Once the UI is validated and stable, add basic testing thru the UI and most importantly, instrument all code to catch production errors and deploy to select customers. Customers will do things developers never expected logging new production errors. When production issues are found, fix then add tests to prevent regression.
Keep in mind that testing can double or triple code in a system and test code requires maintenance like all other code which means time. If there are plenty of resources, time, and funding, then TDD is great. If you’re in a startup and the feature has not been validated by the users and no one is paying for the feature meaning it may be removed completely and replaced with a better feature, then TDD will slow down time to market which can kill a startup. MVPs don’t need extensive test cases like a mature product that generates revenue requires.
This approach provides quickest time to market on new features, the most efficient path to fix issues, and provides test coverage for only real failures minimizing code and extra work.
On large projects with 20+ developers it is very important to have TDD and good test coverage as achieving complete understanding of how all feature work with all team members is impossible. Testing provides immediate feedback when something brakes and automates testing so it can be done before every commit if needed.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Like all things related to software development, it depends. If there are many defined edge cases specified in the design spec then TDD is an efficient method to develop software. When the software is being prototyped for the first time; however, it is faster for the team to build the features, demo, and UX test first as user acceptance always results in more UI changes.
Once the UI is validated and stable, add basic testing thru the UI and most importantly, instrument all code to catch production errors and deploy to select customers. Customers will do things developers never expected logging new production errors. When production issues are found, fix then add tests to prevent regression.
Keep in mind that testing can double or triple code in a system and test code requires maintenance like all other code which means time. If there are plenty of resources, time, and funding, then TDD is great. If you’re in a startup and the feature has not been validated by the users and no one is paying for the feature meaning it may be removed completely and replaced with a better feature, then TDD will slow down time to market which can kill a startup. MVPs don’t need extensive test cases like a mature product that generates revenue requires.
This approach provides quickest time to market on new features, the most efficient path to fix issues, and provides test coverage for only real failures minimizing code and extra work.
On large projects with 20+ developers it is very important to have TDD and good test coverage as achieving complete understanding of how all feature work with all team members is impossible. Testing provides immediate feedback when something brakes and automates testing so it can be done before every commit if needed.