New answers tagged tdd
In my experience the biggest hurdle for TDD is that you need a clear specification and, preferably, traceability between specification items and tests so that if the specification is revised you know which tests to change. Sadly in many organisations that I have worked with the specification is released at Issue 1 between a week and a month after the code ...
What a question to ask! Someone could say TDD is impractical in [situation X] until someone writes a test harness that makes it more practical. I am a rank newbie myself who is trying to learn TDD - so don't rush to accept my answer! I thought TDD would be infeasible for me. I am working with a 16bit uC. I am working through James Grenning's Book. There is ...
Make each test very small and focused. Avoid making tests depend on each other, either explicitly or implicitly. Dependencies among tests are a path to pain, expense, fragility, and complication. I have never seen an exception to this. Ever. Make each test express its intent very clearly. Pay attention to failure messages. Make each failure message as ...
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.
For one it may be that the software will be developed to comply with the predefined tests only...
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 is for testing application. DB schema is not an application and you cannot test it per se. You can test application which uses that schema. Tests will help you determine if your application is still working correctly after refactoring, which may include any changes in the schema (or any other changes).
You start by determining what functionality you expect from it (saving value, retrieve it later, etc) and writing tests for it. It is not different that would be writing tests for any other API.
I started TDD on such a small project, so certainly it IS possible. Limiting factor is not length of a project but how much "plumbing" you need to develop to get your tests going. But if you make decision to use unit tests, you cannot save time by not writing the test - so you may as well to start by writing (failing) unit tests. You will be surprised how ...
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.
For functional/acceptance testing you need working application, so TDD is much better match for unit testing. But you can plan for functional/acceptance testing, and those test plans may influence your design decisions.
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 ...
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 ...
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 ...
Top 50 recent answers are included