Tag Info

Hot answers tagged

6

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 ...


5

The short version: regardless of the development methodology, your role is to provide information about the overall quality of the application. You do that via testing anything that isn't included in the developer-maintained automation, and reviewing the developer-maintained automation. The long version: This question and its answers is a good starting ...


3

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 ...


2

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 ...


2

In my experience, you can't sell new development processes. The only path I've found which works is to simply start doing it: Only develop with TDD from this point forward. You'll still deliver your code on time, but it'll be more maintainable and have far fewer bugs. You'll feel much less anxiety and be proud of your work. After a little time, management ...


2

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 ...


2

Lets assume that you go with the TDD approach to writing your tests. In this case you should be focusing on writing tests for the code you are implementing. If in this case you are working on client side code that makes calls to a server you should be working with unit tests initially that test the calls you are making. Using stubs and mock objects you ...


1

Short answer: Limit refactoring to "removing duplication". This is Kent Beck's summary of the refactoring step in Test-Driven Development by Example. Long answer: the time spent refactoring because of TDD is a blessing, not a curse. It's not a problem that TDD's refactoring takes time ... because in many languages refactoring is only possible because of ...


1

I thought TDD would be impractical / not feasible for me in general because I am working with a 16bit uC. There is no open source test harness that directly compiles in my build environment and the proprietary solutions are pricey. The rest of my answer will be W.R.T. TDD in embedded C. I am working through James Grenning's book and he uses cpputest and ...


1

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 ...


1

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 ...


1

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.


1

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.


1

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.


1

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 ...


1

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.



Only top voted, non community-wiki answers of a minimum length are eligible