TDD (Test Driven development) and Nunit Quick start: A Beginner’s Guide
TDD (Test Driven development) and Nunit Quick start
What Is Test-Driven Development?
Test Types
Black Box vs. White Box Test
Black Box Testing
White Box Testing
One of the biggest challenges you will face when writing units tests is to make sure that each test is only testing one thing. It is very common to have a situation where the method you are testing uses other objects to do its work. If you write a test for this method you end up testing not only the code in that method, but also code in the other classes. This is a problem. Instead we use mock objects to ensure that we are only testing the code we intend to test. A mock object emulates a real class and helps test expectations about how that class is used. Most importantly, mock objects are:
- Easy to make
- Easy to set up
- Fast
- Deterministic (produce predictable results)
- Allow easy verification the correct calls were made, perhaps in the right order
The following example shows a typical mock object usage scenario. Notice that the test code is clean, easy to understand and not dependent on anything except the code being tested.
namespace UnitTestingExamples.Tests {
|
As you can see, the MockDatabase was easy to setup and allowed us to confirm that the Save method made certain calls on it. Also notice that the mock object prevents us from having to worry about real databases. We know that when the ModelClass saves itself, it should call the database’s Update method twice. So we tell the MockDatabase to expect two updates calls, call Save and the confirm that what we expected really happened. Because the MockDatabase doesn’t really connect to a database, we don’t have to worry about keeping “test data” around. We only test that the Save code causes two updates.
“When Mock Objects are used, only the unit test and the target domain code are real.” — Endo-Testing: Unit Testing with Mock Objects by Tim Mackinnon, Steve Freeman and Philip Craig.
Q.How I will use it [Practical Approach]?
Ans. Till this we have seen a lots of Theory and concepts about Nunit and eager to apply it ??. just follow the steps given as under
- Create a Console Application name it “HelloUnit Test”.
-
Right Click on Reference and click on Add Reference.
-
Click on browse and Select nunit.framework.dll
Figure 1 : Located at ‘c: \Program Files\Nunit 2.4.6\bin’
- Add New Class file to your project [which we will use for Writing Test] and name it ‘MyTest’
-
For making ‘MyTest’ Testable by Nunit we have to do some steps.
- Reference to Nunit namespace by using NUnit.Framework;
-
Make It public and provide attribute [TestFixture]
- [Optional] Create a Public Constructor. [Otherwise CLR will have it so not needed].
- Create a method which will be tested by Nunit. Inshort create one Method with Public Void, no parameters and attributed as [Test]
- Reference to Nunit namespace by using NUnit.Framework;
-
Starting Nunit GUI for Testing
- You can open it from ‘C:\Program Files\Nunit 2.4.6\bin\nunit.exe’.
-
OR Choose it from Start menu or Shortcut Icon on desktop
-
To Load your Assembly Click on File->Open Project
-
Select you Assembly [HelloUnitTest.exe]. @ path ‘../ HelloUnitTest\bin\Debug’.
-
Click on Open you will see a screen like this
-
Click on Run. If green bar comes means your test has been run successfully.
- You can open it from ‘C:\Program Files\Nunit 2.4.6\bin\nunit.exe’.
-
Let us add something to test.[To fail the test]
-
Now compile your solution and Press the Run button Again. You will see the screen like below. [Which says that Test Method has been failed]
- Now I think you can try on yourself all the Attributes like [SetUp], Teardown etc.
- I have used the [Setup] like this.
| using System; using System.Collections.Generic; using System.Text; using NUnit.Framework; namespace HelloUnitTest {
[TestFixture]
{
[SetUp]
{ i = 1; } [Test]
{
} } }
|
References and Links
Kent Beck, in his book Test-Driven Development: By Example (Addison-Wesley Professional, 2003), defines test-driven development using the following rules:
- Never write a single line of code unless you have a failing automated test.
- Eliminate duplication.
The first rule is straightforward: don’t write code without having a failing automated test because the tests embody the requirements that the code must satisfy, as stated in the Introduction. If there is no requirement (that is, test), there is no need to implement anything. This rule prevents us from implementing functionality that is not tested and not needed in the solution.
The second rule states that no code should be duplicated in the program. Code duplication is the epitome of bad software design; it leads to inconsistency problems and a reduced level of confidence in the program over time as people forget where the duplications are. If there is code duplication, it is the programmer’s job to remove it when it is seen. (In Extreme Programming [XP], this rule is called “Once and Only once!”)
| Kent’s definition does not make a distinction between different types of tests[1] . All he says is that the tests have to be automated, which we agree with entirely. However, it is useful to categorize the test types around the constituents who produce them—for example, customers who specify the functionality, programmers who implement the functionality, and testers who support development during the development of the code and critique the final result after the code is complete. The two constituents that this book focuses on are programmers and customers. | ||||
Programmer Tests
If we are talking about the programmers writing the code, it is useful to think of these tests as focused on technology, so you can refer to them as technology facing or programmer tests. Some people refer to this type of test as a unit test; we are specifically not calling it that because unit testing’s purpose is much different from what we are doing in TDD. Because the audience for these tests is programmers, it is critically important that the tests be written in a language that the programmers understand. (It’s even better if they are in the same language as the production code.) If the tests are in the same language, the programmer doesn’t have to change paradigms to write tests.
Customer Tests
Tests that customers use to specify the functionality they need and how it should work can be referred to as business facing or customer tests. These types of tests are often referred to as acceptance tests or functional tests. As in the case of programmer tests, the tests need to be written in a language that the customer understands. The goal is to empower the customer to be able to write tests.
Conclusion: Nunit comes in First type means Programmer Tests
Black box testing is different from white box testing. The kind of testing that you can perform on the code determines, among other things, the complexity of the unit test.
A black box test (also known as a “functional test”) is one in which you feed it inputs and verify the outputs without being able to inspect the internal workings. Furthermore, one doesn’t usually have information regarding:
- how the box handles errors
- whether your inputs are executing all code pathways
- how to modify your inputs so that all code pathways are executed
- dependencies on other resources
Black box testing limits your ability to thoroughly test the code, primarily because the you don’t know if you’re testing all the code pathways. Typically, a black box test only verifies that good inputs result in good outputs (hence the term “functional test”).
Classes are often implemented as black boxes, giving the “user” of the class access only to the public methods and properties that the implementer selected.
A white box provides the information necessary to test all the possible pathways. This includes not only correct inputs, but incorrect inputs, so that error handlers can be verified as well. This provides several advantages:
- you know how the box handles errors
- you can usually write tests that verify all code pathways
- the unit test, being more complete, is a kind of documentation guideline that the implementer can use when actually writing the code in the box
- resource dependencies are known
- internal workings can be inspected
In the “write the test first” scenario, the ability to write complete tests is vital information to the person that ultimately implements the code, therefore a good white box unit test must ensure that, at least conceptually, all the different pathways are exercised.
Another benefit of white box testing is the ability for the unit test to inspect the internal state of the box after the test has been run. This can be useful to ensure that internal information is in the correct state, regardless of whether the output was correct. Even though classes are often implemented with many private methods and accessors. With C# and reflection, unit tests can be written which provide you the ability to invoke private methods and set/inspect private properties.
Q. what are Unit Tests?
Ans. According to Ron Jeffries, Unit Tests are “programs written to run in batches and test classes. Each typically sends a class a fixed message and verifies it returns the predicted answer.”
Q.What is Nunit?
Ans. Nunit is mostly used for Testing from so many times. Those systems provide base classes from which you have to derive your class and do its testing. But honestly speaking they also have some restrictions because C# only allows single inheritance. But .NET has introduced new concept to programming that solves this problem which is called Attribute. Attribute allows you to add metadata to your code. They don’t affect your code but it provides extra information about your code. It provides information to others. Using this feature exactly Nunit works. The Test Runner application scans your compiled code looking for attributes that tells it which classes and methods it have to use for testing. It then use Reflection to execute those methods. Nunit provides verity of attributes like Test Fixture, Test etc. which we will see in next section.
Q. Nunit Core Concepts or Attributes
Ans.
TestFixture Attribute
This attribute is to specify the class that contains the test case. This attribute is placed before the classes that contain test code.
When you attach this attribute to a class in your project, the Test Runner application will scan it for test methods.
 using System;using NUnit.Framework; namespace NUnitCoreConcepts { [TestFixture] public class CoreConcepts() { … } } |
NOTE: 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. Because CLR itself provides default constructor which is public).
[TEST] Attribute
The [Test] attribute specifies the Test Methods inside the Test Class. The Test Methods are the methods that contains code for testing.
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
| using System; using NUnit.Framework; namespace NUnitCoreConcepts { [TestFixture] public class CoreConcepts { [Test] public void AdditionTest() { int num1 = 3; int num2 = 4; Assert.AreEqual(7, num1 + num2); } } } |
Assertions
In NUnit, Assertions are the way to determine whether the Test Code in the Test method passed or failed. In the above example ASSERT.AREEQUAL () method verifies the actual and expected and says whether the test passed or not. There are many static methods in Assert class. Some of them are
Assert.AreEqual()
Assert.IsTrue()
Assert.IsNull() …
namespace UnitTestingExamples {
|
[Setup] Attribute [TearDown] Attribute
The [Setup] attribute specifies the method that has to be executed before every Test method is executed. It normally contains initialization code.
The most common use for these attributes is when you need to create dependent objects (e.g., database connections, etc.).
The [TearDown] attribute specifies the method that has to be executed after the Test method is executed. Its normally contains code to release the resources.
| using System; using NUnit.Framework; namespace NUnitCoreConcepts { [TestFixture] public class CoreConcepts {
private int num2 ; [SetUp] public void Init() { num1 = 3; num2 = 4; }
[TearDown] public void TearDown() { NUM1=0; NUM2=0; }
[Test] public void AdditionTest() { Assert.AreEqual(7, num1 + num2); } } } |
private int num1 ;
ExpectedException Attribute
ExpectedException attribute specifies that executing the test code would raise an exception. See the example below
| using System; using NUnit.Framework; namespace NUnitCoreConcepts { [TestFixture] public class CoreConcepts { [Test] [ExpectedException(typeof(DivideByZeroException))] public void DivideByZeroExceptionTest () { int zero = 0; int num = 100; int result = num / zero; Assert.Fail(“We are failing the test if it doesn’t raise an divide by zero exception”); } } } |
When this code runs the test will pass only if it throws an exception of type DivideByZeroException
Let us write some code using it.
Ignore Attribute
To indicate that this test should not be run now. Probably You won’t use it than also just for knowledge keep it in mind.
| using System; using NUnit.Framework; namespace NUnitCoreConcepts { [TestFixture] public class CoreConcepts { [Test]
public void DivideByZeroExceptionTest () { int zero = 0; int num = 100; int result = num / zero; Assert.Fail(“We are failing the test if it doesn’t raise an divide by zero exception”); } } } |
Q. How to Run your Test?
NUnit comes with two different Test Runner applications: a Windows GUI app and a console XML app. Which one you use is a matter of personal preference. To use the GUI app, just run the application and tell it where your test assembly resides. The test assembly is the class library (or executable) that contains the Test Fixtures. The app will then show you a graphical view of each class and test that is in that assembly. To run the entire suite of tests, simple click the Run button. If you want to run only one Test Fixture or even just a single test, you can double-click it in the tree
There are situations, particularly when you want to have an automated build script run your tests, when the GUI app isn’t appropriate. In these automated builds, you typically want to have the output posted to a website or another place where it can be publicly reviewed by the development team, management or the customer. The Nunit 2.0 console application takes the assembly as a command-line argument and produces XML output. You can then use XSLT or CSS to convert the XML into HTML or any other format. For more information about the console application, check out the Nunit documentation.
A Place for C Sharpers/.Netters 
A very good article to start with nunit.