tags:

views:

485

answers:

4

Can someone explain me how it works, starting from when you select to run a test

A: 

What do you mean how does it work?

You define your test classes with [TestFixture] and your tests with [Test]

It's nothing more than a testing framework, you still have to write the tests and all of that jazz :)

Ian P
+1  A: 

I use it at work, but I'm not an expert. Here's a link to the NUnit documentation: http://www.nunit.org/index.php?p=getStarted&r=2.4.8

John Ferguson
+1  A: 

1) Have a class you want to test in a .NET project (MyClass is the class name, MyProject is the project name, for example)

2) Add another project to your solution called MyProject.Tests

3) Add a reference from MyProject to MyProject.Tests so that you can access the class you want to test from the testing code

3) In this new project add a new class file called MyClass (the same as the class in MyProject)

4) In that class, add your testing code like this page explains -- http://www.nunit.org/index.php?p=quickStart&r=2.4.8

5) When you've written your tests, build the solution. In the MyProject.Tests project folder a new folder will appear -- 'MyProject.Tests\bin\Debug'. That's assuming you built in Debug mode. If you built in Release mode it'll be MyProject.Test\bin\Release. Either will work. In this folder, you'll find a dll file called MyProject.Tests.dll

6) Open the nUnit testing utility, File > Open, then navigate to the folder in #5 to find that MyProject.Tests.dll. Open it.

7) The tests from the dll should be listed in the nUnit utility window, and you can now select which tests to run, and run them.

Note: The naming convention isn't necessary, it's just the way I do it. If you have a project called 'MyProject' and you want your testing project to be called 'ArbitraryName' instead of 'MyProject.Test', then it'll still work... the naming convention just helps keep track of what exactly is being tested.

Pete Michaud
The .Tests naming convention comes from CruiseControl.NET NAnt scripts that are accompanied with it. The scripts are grabbing unit test assemblies ending with ".Tests".
Patrick Peters
+3  A: 

When you select to run a test,

  • it will create an instance of the parent class of that test method.
  • It then proceeds to run the method marked with TestFixtureSetup attribute if one exists (once for the the test class).
  • Next is the method marked with the Setup attribute is called if one exists (once before every test in that class)
  • Next your selected method (with the Test attribute) is executed. All assertions are checked. If all assertions are valid, the test is marked as Pass (Green in the GUI) else Fail (Red). If any exceptions pop up that were not specified with the ExpectedException attribute, test fails.
  • Then the method marked with the Teardown attribute is called if one exists. (Cleanup code.. called once after every test in the class)
  • Finally method marked with TestFixtureTeardown attribute is executed. (once after all tests in the test class)

That's it in a nutshell. The power of xUnit is its simplicity. Is that what you were looking for ?

Gishu