Menu
I see lots of TDD practitioners following this cycle:
1) Write your test as if the target objects and API already exists.
2) Compile the solution and see it break.
3) Write just enough code to get it to compile.
4) Run the test and see if fail.
5) Write just enough code to get it to pass.
6) Run the test and see it pass
7) Refactor
What is the advantage of steps 1 and 2? With IDEs like Visual Studio this is really annoying to do, since intellisense jumps all over the place trying to guess methods and attributes that are not there.
I usually start on step 3, having all my methods throwing NotImplementedException, and this seems perfectly fine for me, but maybe I am missing something.
Edit for clarification: this is not a question why I should see a test fail before it passes; that is covered on step 3 onwards, and it makes total sense. My question is why even before that people will call a method on the unit test that doesn't exist in the API (therefore VS will show a red squiggle, or paint the whole method name red etc) and try to compile anyway. For me the fact that VS is telling me that the method does not exist is good enough.
774
Fewer bugs and errors are the primary benefit of the TDD approach. When the code has fewer bugs, you'll spend less time fixing them than other programming methodologies. TDD produces a higher overall test coverage and, therefore to a better quality of the final product.
And as you write the test first, the code automatically becomes easy to check. Code that's easy to check features a clear interface. This leads to a modular design for your application.
Tests can be set to run either a one-time check at a certain time interval or can be run immediately in real-time to review changes. In short, unit tests help developers detect problems immediately, then fix them quickly. With fewer resources spent finding bugs, teams can move on to the next phase of a project.
TDD makes refactoring and maintenance much easier. As all functionality is covered by tests, any change in code that might introduce an error is easily detectable, since unit tests begin to fail. This way, developers can be sure that when they revisit prior version code, changes can be made with confidence.
Then try it by writing the method name first. I find by writing the test first and the methods, it forces me to really think about the API, and I'm free to easily change names without having to worry about code that has already been written. My suggestion would be to try not following the rules, and monitor what happens. If you find that it causes problems, switch back. And if it doesn't, you've got a new way of working now.
Remember also that when you are first learning about things, generally you need a clear set of rules to give you context. As you begin to move from Beginner to more advanced, you'll gain more context and be able to make tweaks. It sounds to me like that's where you are.
63
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
