Test Driven DevelopmentIs an approach to design better software. Test Driven Development (TDD) starts the development cycle with gathering requirements, but then quickly moving to writing test cases that document the requirement and force the designer to think about exactly what the system is supposed to do. It takes automated unit testing and regression testing and makes them a basis for all development activities. This means that when adding new functionality a test is written first, it will fail this test at first, then as it is implemented it will eventually pass the test. The best part is now refactoring can take place because we have regression testing already in place to verify by refactoring that we did not break anything. This promotes clean, clear, modularized code because if you can test the code it is likely that it is modular and easier to maintain.
TDD Advantages Some TDD advantages are as following:
Safe Refactoring When you use TDD, because you have tests already written, you can easily refactor your existing code and you can still be sure that your code does what it needs to be doing, because you have tests.
More Testable Software Design As explained in the refactoring section, TDD helps you design your software for testability, so it will be loosely coupled and more maintainable.
You will have more modularized, flexible, and extensible code which guarantees the Code Quality.
Automated Testing After you created the tests, you can run all the tests at the same time, also you can use some tools like CruiseControl.Net to automate the tests.
Automated Testing significantly reduces the time taken to retest the existing functionality for each new build of the system.
Change Cost Reduced The reason is you have tests, so the change you make has very controllable effect on your system, though it depends on the type of change. In the other words, the Developer will have more confidence on making the decisions and applying the changes.
Greater Reliability & Reduced Debugging Time The reason is you have tests to cover all the production code, so the bugs are caught in the Testing Framework.
Test Cases as Documentation It is very important that the developer has a clear understanding of the specifications and requirements as TDD is applied and the fact is the test cases will be gradually a good source of documentation for your software functionalities.
Requirements Better Detailed TDD helps better understanding of the requirements, analysis and design because the developer cannot create the production code without truly understanding what the desired result should be and how to use it and this approach is done in an iterative manner.
TestFixture AttributeThe TestFixture attribute is used to indicate that a class contains test methods. When you attach this attribute to a class in your project, the Test Runner application will scan it for test methods. The following code illustrates the usage of this attribute. (All of the code in this article is in C#, but NUnit will work with any .NET language, including VB.NET. See the NUnit documentation for additional information.)
namespace UnitTestingExamples
{
using System;
using NUnit.Framework;
[TestFixture]
public class SomeTests
{
}
}
The only restrictions on classes that use the TestFixture attribute are that they must have a public default constructor (or no constructor which is the same thing).
Test AttributeThe Test attribute is used to indicate that a method within a test fixture should be run by the Test Runner application. The method must be public, return void, and take no parameters or it will not be shown in the Test Runner GUI and will not be run when the Test Fixture is run. The following code illustrates the use of this attribute:
namespace UnitTestingExamples
{
using System;
using NUnit.Framework;
[TestFixture]
public class SomeTests
{
[Test]
public void TestOne()
{
// Do something...
}
}
}
SetUp & Teardown Attributes
Sometimes when you are putting together Unit Tests, you have to do a number of things, before or after each test. You could create a private method and call it from each and every test method, or you could just use the Setup and Teardown attributes. These attributes indicate that a method should be executed before (SetUp) or after (Teardown) every test method in the Test Fixture. The most common use for these attributes is when you need to create dependent objects (e.g., database connections, etc.). This example shows the usage of these attributes:
.png)
