Aktuelle Änderungen Printable View Änderungen Bearbeiten
TFS > TeamFoundationServer > TShirts > TailCallElimination > Recursion > TailCallOptimization > Recursion > TailRecursionElimination > Recursion > TddScratch > TeamFoundationServer > TeamFoundationVersionControl > Technorati > TedNelson > TemplateDriven > TestDriven > TestDrivenDevelopmentClear Traila cool and useful design-method
The great advantage of TDD is not that you end up with a well tested application, but that it changes the way you develop code. By writing unit tests before the code it is testing, you have to write modular decoupled code. It forces you to think about what API you want, instead of just banging out the code and ending up with whatever API results. Inevitably writing testable code results in better code. Writing the tests becomes part of the way you approach problems and think about API design. [1]
This concept was invented in the early 1990s in the Smalltalk world, when Kent Beck wrote SmalltalkUnit.
It might (finally) turn software from an amateur’s kitchen to an engineering discipline.[2]
For low-level core infrastructural pieces, the addictiveness of this approach is just beyond words.[3]
How do you know if your unit tests are small/isolated/discrete enough? Easy, VS.NET debugger sessions become uncommon and short and test failures are easily diagnosed and remedied.[4]
TDD is a technique for determining class structure by making testability a first class consideration in your design. Focusing on testing a unit of code at a time leads to creating cohesive classes with a distinct purpose and responsibility.
When you have a test-infected project, one of the side effects is that you are able to treat structure and correctness orthogonally.
The core, though, is that TDD is more about design than testing. When you write tests first, it makes coupling painful, so you avoid coupling.
The Testivus Manifestivus
Less testing dogma, more testing karma
Any tests are better than no tests
Testing beats debugging
Test first, during, or after – whatever works best for you
If a method, technique, or tool, gives you more or better tests use it
But here is my real secret: most of the time, I don't use a debugger to debug. I use it to verify that my code works as I think it does.
The use of a debugger is an entirely different question. I certainly occasionally use it for exploratory testing, looking at other peoples code. However my use of a debugger for figuring out why the code I've just written has dropped to pretty close to zero.
Developers do white-box testing via unit tests, while testers do mostly black-box testing (or maybe gray-box, since they usually do have some insight into the inner workings of the application) via functional, integration and system testing.[5]
In fact, as Amir Kolsky remarked on the agile-testing list, TDD itself can be seen as black-box testing, since when we unit test some functionality, we usually test the behavior of that piece of code and not its implementation, thus we're not really doing white-box testing. [6]