Hot answers tagged tdd
The first thing you want to do here is perform some bug triage. Problems your team finds during feature testing will be one of: something introduced by the changes something that was there before and doesn't have much if any impact on the changes something that was there before and has a major negative impact on the changes The developers in the team ...
Taking the waterfall model in agile would be a good idea but there seems to be a misunderstanding on your part regarding the concept of test driven development. Test driven development doesn't mean agile, neither does it mean just writing test cases early. It means that tests are written first and these tests drive the programming. That means the ...
In TDD you write the minimum amount of code to pass the test case. That test case, of course, should only be testing at a unit level. You want to test individual pieces, so you write test cases to cover limited functionality(mainly 1 feature). Your test cases will end up acting as documentation for your system and low-level regression testing. TDD is ...
This book is exactly what you need: Working Effectively with Legacy Code by Michael Feathers. Michael offers several approaches to TDDing legacy code. One of those is: Before you add a new feature, write tests in the area that you will change. This approach gives a number of benefits: Writing the tests will give you a certain amount of confidence that ...
TDD focuses on very small pieces of code. Classes or methods or (in some cases) very small groups of tightly collaborating objects. There are test-driven techniques that focuses on a larger scope. Two of these are Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD). To my eye, these approaches are similar in intent, though BDD ...
The one situation where I've found TDD unworkable: If other people are changing the same code without using TDD, or without at least keeping the existing tests current as they change the code. You could count that as a disadvantage: You can't effectively adopt it by yourself if you're working with others on the same codebase.
You should teach developers to write tests Test writing is time consuming It's complicated to judge test completeness TDD may not work due to project workflow and features TDD doesn't give you confidence that the code works You should rewrite tests too after changing some API, for example.
This book is exactly what you need: Working Effectively with Legacy Code by Michael Feathers. That book goes directly to both of your questions: How to start refactoring a legacy codebase, and how to approach TDD when the code is not yet testable. Underlying both of those questions is another that the book answers: How to get a legacy codebase under test.
It really doesn't work that way. Test-Driven really means that the tests come before the code. So if you already have the code, it's too late to test-drive it. What you can do, on a project which did not initially use TDD, is to start using it. So before you write any new code, you write the test first. Gradually that will add coverage to your existing ...
Only top voted, non community-wiki answers of a minimum length are eligible