Introduction:
I'm totally new to TDD world. I saw many sample open source projects that based on TDD and DDD but I explored only 2 of them, the MVC Storefront and Kigg (see it live). I was very lucky actually to go deep with Kigg source code and I found it one of the most clean and testable code I ever seen. With out single line of comment you can understand what this code is doing. Special thanks to Kazi Mansur Rashid every member of this project for such great work.
Quotes:
This encourage me to start practically learning TDD and apply it. So I started to search about TDD. In the following few lines I am going to list few quotes I caught from different sources:
"Test-driven development (TDD) is a software development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions. Each iteration produces code necessary to pass that iteration's tests. Finally, the programmer or team refactors the code to accommodate changes. A key TDD concept is that preparing tests before coding facilitates rapid feedback changes. Note that test-driven development is a software design method, not merely a method of testing" -Source: Wikipedia-
"The first step is to quickly add a test, basically just enough code to fail. Next you run your tests, often the complete test suite although for sake of speed you may decide to run only a subset, to ensure that the new test does in fact fail. You then update your functional code to make it pass the new tests. The fourth step is to run your tests again. If they fail you need to update your functional code and retest. Once the tests pass the next step is to start over (you may first need to refactor any duplication out of your design as needed, turning TFD into TDD)." -Source: agiledata.org, Introduction to Test Driven Design (TDD)-
"Test-driven development (TDD) is an advanced technique of using automated unit tests to drive the design of software and force decoupling of dependencies. The result of using this practice is a comprehensive suite of unit tests that can be run at any time to provide feedback that the software is still working. This technique is heavily emphasized by those using Agile development methodologies. The motto of test-driven development is "Red, Green, Refactor. Where Red: Create a test and make it fail, Green: Make the test pass by any means necessary. Refactor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass" -Source: MSDN, Guidelines for Test-Driven Development by Jeffrey Palermo-
My thoughts:
TDD isn't something new, but lately there was a loud talks around the community about it. Anyway after reading the above introduction quotes, I start to compare them. They are all agree you start by writing your test scenarios (coding them). Then you run them to fail. Later you start the iteration of fixing your code to make it pass the test. And finally you do refactoring. Maybe the word finally isn't the correct word, for me refactoring will be an occurring task that you'll keep doing to optimize your code and keep it clean.
One good thing about TDD is that your code will be CLEAN. I tried it myself and soon I'll share my code which I made against Entity Framework. My learning source was Kigg.
TDD & Entity Framework:
While I was trying to write tests for my Entity Data Model, I realized that my tests will require to hit the database!! Which is acceptable in case I am doing integration testing. So I had to find another way to apply TDD with EF. Kigg was the key for the solution because it does the same with LINQ to SQL, However, EF and LINQ to Entities is different than LINQ to SQL. Many things that are supported and expected work with LINQ to SQL and LINQ to Object just don't fit with LINQ to Entities. You can have read my posts regarding such not supported features in LINQ to Entities.
Guidelines listed at "Guidelines for Test-Driven Development" by Jeffrey Palermo made my understand to Unit testing in TDD clear. I am going to list few of these guidelines but I hardly recommend that you have a look at them because they aren't too much:
- Separates or simulates environmental dependencies such as databases, file systems, networks, queues, and so on. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
- Runs and passes in isolation. If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests. Change them for simplicity and reliability. Tests should run and pass on any machine.
- Often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
- Clearly reveals its intention. Another developer can look at the test and understand what is expected of the production code.
That was all for this post, soon I'll start to post about TDD & DDD with samples. And I will show how to follow TDD while working with Entity Framework and being independent of it. The above guidelines where like magic words to me. Keep tuned.