Lately, I have been surrounded by NUnit in my daily conversations.
1. It is probably that I am a tester, I somehow got to write/improve some unit tests;
2. NUnit has quickly become a general practice (standard) among my product team where more developers, PM and testers have been pushing this neat practice;
3. NUnit has grown out of its design role among my test organization (I will explain later in this post)
First of all, you can find NUnit here. Let me introduce NUnit to people who have not used yet.
A simple test can be created with following few lines of code:
[TestFixture]
public class SampleTest
{
[Test]
public void MyTest()
{
Assertion.Assert(“This is MyTest“, 1=2);
}
}
If you need more information about NUnit, please check out their documentation.
In addition to the NUnit which developers and testers can use for Windows-based applicaiton, NUnit has a version for ASP.NET (hear from my co-workers, I believe that it is still in beta) as well.
What have made NUnit a such interesting tool is that testers can leverage NUnit to do some cool testing practices.
- NUnit attributes can be extended by writing custom attributes by developers and testers;
- With a great number of unit tests, anyone can write a not-so-difficult .NET application with Reflection to discover NUnit unit tests by their attributes and invoke them one by one.
The advantages of using NUnit in normal testing scenarios are:
- Without too much code, testers can acquire coverage number on applications with an instrumentation tool;
- A suite of NUnit unit tests can set the minimum requirement for a code's minimum functional screening; therefore, this ensures that tester will not spend time on a broken build;
I think I will stop here for the day. As of myself, I am still exploring NUnit, I have been using it for a while now; however, with much more possiblity NUnit presents with other great tools, a tester nowadays can achieve many things without too much effort.
