All unit testing frameworks share the same core features: test declaration, test execution, and pass/fail notices based on assertions. The shop I work at has been using NUnit for over two years now, with great success. We considered switching to MBUnit a year and a half ago, primarily because of Gallio’s compelling nature, but didn’t pull the trigger because of NUnit’s fluent interface and MBUnit’s lack thereof. Yes, we could have spun up our own fluent interface for MBUnit, but we preferred spending time solving business problems instead.
All that said, now that we’ve finally secured our Visual Studio 2010 licenses, we decided to give another look at MSTest to see how it would stack up given our day to day usage. We have three primary criteria when it comes to a unit testing tool:
- Be amenable to test driven development
- Stay out of the way
- Allow for readable tests sans comments
This post will compare MSTest to NUnit in Visual Studio 2010 to see how the two frameworks stack up from the perspective of those three criteria. It’s a fight to the end!
The Problem Space
For our examination, we will spin up a framework upon which we can build game board objects. Think Tic Tac Toe or Connect Four. Our boards will have a number of rows and columns, will have two or more players, and each position on the board will be occupied by at most one player. We will code to the below interface layout.
We’ll write up an implementation that represents a Tic Tac Toe board. Since we’re aspiring to TDD, we need to wire up our tests first. To do that, we need to prepare our environment.
Environment Prep – MSTest
All you have to do to add a test project to your solution is to, well, add a test project to your solution. Right-click on the solution node and click Add –> New Project.
Then expand the Visual C# node in the list of installed templates and select the Test option. There should only be one project type that is subsequently displayed in the middle portion, named Test Project. Select that and give your new test project a descriptive name. In our case, we’ll call it GameBoardTests.
Then click OK and let Visual Studio do its thing for a few seconds. Once it’s done, you’ll see a brand new test project added to your solution. Visual Studio was even nice enough to add a new unit test class file for you called Unit Test1.cs. We’ll look at the code in this file when we actually start writing tests.
Environment Prep – NUnit
To get started with NUnit, you first have to go out and download the latest version. We mosey on down to the NUnit home page and click on the Download menu option at the top. As of this writing we see that the latest version is 2.5.5, so we download the msi and install it, taking note of the install location.
After that, we have to add another test project to contain our NUnit unit tests. We could have added these to the MSTest project that Visual Studio created for us, but I want to keep our comparison as much apples to apples as possible. For our NUnit tests, we’ll add a regular old class library project called NUnitGameBoardTests so that the distinction is painfully clear. This should give us a solution similar to the below.
Environment Prep Winner – MSTest
MSTest’s tight integration with Visual Studio pays off here. It’s virtually brainless to get going with it, whereas it takes a non-trivial amount of extra work to get NUnit ready to go.
Our First Test – MSTest
Our first logical test will ensure that when we create a Tic Tac Toe board, we have three rows and three columns. This will take the form of two physical tests, one to test the rows, and another to test the columns. Let’s pop open the source to the unit test that MSTest gave to us for free and see if we can actually use it.
using System;
using System.Text;
using System.Collections.Generic;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace GameBoardTests
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
}
}
}
Looks like your standard unit test shell. We’ll go ahead and rename this class and file TicTacToeBoardTests and write our first test, namely to test whether or not our board has three rows.
[TestMethod]
public void BoardHasThreeRowsTest()
{
TicTacToeBoard b = new TicTacToeBoard();
Assert.AreEqual(b.Rows, 3);
}
Simple stuff, though I am definitely missing NUnit’s fluent interface which we’ll see below. Obviously I can’t yet run our test as I haven’t defined the TicTacToeBoard class yet. Let’s go ahead and do that, along with the stub code that we need to compile after we declare our new class as implementing the IBoard interface (yes, let the TDD purists gnash some teeth).
public class TicTacToeBoard : IBoard
{
public int Rows
{
get
{
throw new NotImplementedException();
}
set
{
throw new NotImplementedException();
}
}
public int Columns
{
get
{
throw new NotImplementedException();
}
set
{
throw new NotImplementedException();
}
}
public ICollection<IPlayer> Players
{
get
{
throw new NotImplementedException();
}
set
{
throw new NotImplementedException();
}
}
public bool MakeMove(int x, int y, IPlayer mover)
{
throw new NotImplementedException();
}
public IPlayer Winner
{
get { throw new NotImplementedException(); }
}
}
We need to add a reference to the MSTest test project for our GameBoards project, import the GameBoards namespace, and then finally we are off to the compilation races.
To run our test, all we have to do is right-click anywhere in the test body and select Run Tests.
You’ll note that I have another similar menu option called “Run Test(s)” in my context menu; this is for the awesome TestDriven.NET tool that no .NET developer should be without. That said, we won’t be using it during this demonstration, as we are testing out-of-the-box implementations only.
After running my tests, I get exactly what I expected: failure.
Double-clicking on the error row takes me to the code that threw the error; this is a place where the tight integration with Visual Studio pays off. So we have basic test authoring, execution, and result checking covered, let’s get our tests passing. We’ll go ahead and wire up the row and column logic into the constructor of the tic tac toe board and create backing stores for the Row and Column properties of our class.
public TicTacToeBoard()
{
Rows = 3;
Columns = 3;
}
private int _rows;
public int Rows
{
get
{
return _rows;
}
set
{
_rows = value;
}
}
private int _columns;
public int Columns
{
get
{
return _columns;
}
set
{
_columns = value;
}
}
With this code in place, our test now passes.
Given that the test that checks if we have three columns is pretty much the same thing, we’ll skip any detail on that here.
Our First Test – NUnit
With the work to get our tests passing performed up above, we can simply concentrate on wiring up NUnit to our project in this section. The first step is to add a reference to NUnit from our NUnit test project. You’ll find the needed reference in the Extensions group, as shown below.
With the NUnit reference added, we’ll rename our default class file to match the one that is in the MSTest test project. Then we add a reference to our GameBoards project as well, and pop open the test class file.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using GameBoards;
namespace NUnitGameBoardTests
{
public class TicTacToeBoardTests
{
}
}
As can be expected, there’s nothing here since this is just the empty class shell that Visual Studio provided for us when it created the class library project. Indicating that this class file is a unit test is done in the same way that MSTest does it, namely by adoring the class and subsequent methods with test attributes. We’ll import the NUnit.Framework namespace and write our test as below.
using NUnit.Framework;
using GameBoards;
namespace NUnitGameBoardTests
{
[TestFixture]
public class TicTacToeBoardTests
{
[Test]
public void BoardHasThreeRowsTest()
{
TicTacToeBoard b = new TicTacToeBoard();
Assert.That(b.Rows, Is.EqualTo(3));
}
}
}
Now the next step is to run it, as before. Right-clicking on the test doesn’t produce the nice little green arrow with the Run Test option anymore, however. I could use my fancy TestDriven.NET tool to run the test, but as I said above, that would be cheating given that TestDriven.NET is a third party tool that requires a purchase. Thankfully NUnit comes with its own test runner that we can use to run our tests. To use it, we have to browse to NUnit’s installation directory and launch the nunit.exe application.
This gives us the NUnit test runner in all of its glory.
Beautiful, yet worthless at this point. To get this to run our tests, we have to load up the DLL that is created when our NUnit test project is built. To do that, we’ll have to create an NUnit test project into which we can load any test DLLs we want to inspect and run. Creating a new project is straightforward, we’ll skip over that step. To add your test DLLs to the newly created NUnit test project, we have to click on Project –> Add Assembly and then browse to the bin\Debug folder where our NUnitGameBoardTests.dll file is found. After we select that, our NUnit interface changes a bit.
It’s a pretty straightforward interface. To run our test, we can either double click its name or just click the Run button from any of our test’s parent nodes in the left treeview.
Finally we have an indication that our tests passed as MSTest did. Note that one of the consequences of having to load our test DLL like this is that we have to rebuild it for the NUnit test runner to detect any changes in the test suite.
Our First Test Winner – MSTest
MSTest wins this round, again due to its tight integration with Visual Studio. With NUnit, we’re now saddled with an extra program that we have to run, and we have to build our test project before running our tests, a step I’m sure many developers will forget to do every now and then, enough so to cause consternation. While this determination isn’t based solely on the test content as our subsequent test comparisons will be, we have to take these additional dependencies into account somewhere, so we’ll just go ahead and do it here.
Our Second Test – MSTest
Our second test is to ensure that our tic tac toe board comes with exactly 2 players, and appears below.
[TestMethod]
public void BoardHasTwoPlayersTest()
{
TicTacToeBoard b = new TicTacToeBoard();
Assert.AreEqual(b.Players.Count, 2);
}
Simple enough. We go ahead and augment the constructor to create two players for us, and wire up the corresponding property to a backing store. We go ahead and create a Player object that implements the Player interface with a default implementation so we can make the compiler happy.
First our Player class.
public class Player : IPlayer
{
public string Name
{
get
{
throw new NotImplementedException();
}
set
{
throw new NotImplementedException();
}
}
}
Our new Players property.
private ICollection<IPlayer> _players;
public ICollection<IPlayer> Players
{
get
{
if (_players == null)
{
_players = new List<IPlayer>();
}
return _players;
}
set
{
_players = value;
}
}
And finally our new constructor.
public TicTacToeBoard()
{
Rows = 3;
Columns = 3;
Players.Add(new Player());
Players.Add(new Player());
}
The test now passes, and we have verified that we have exactly two players after instantiating our tic tac toe board.
Our Second Test – NUnit
Again, since we went through the pains of actually getting our test to pass while working with MSTest, this section will be quick and painless. The NUnit test is below.
[Test]
public void BoardHasTwoPlayersTest()
{
TicTacToeBoard b = new TicTacToeBoard();
Assert.That(b.Players.Count, Is.EqualTo(2));
}
Our Second Test Winner – Draw
Nothing crazy went on in our second test, and since we had our environments set up already, the effort to get these working was bordering on trivial.
Our Third Test – MSTest
Our third test will ensure that we have two players with the right names, namely one as “Nought” and the other as “Cross.” The MSTest test is below.
[TestMethod]
public void BoardHasRightPlayersTest()
{
TicTacToeBoard b = new TicTacToeBoard();
Assert.AreEqual(b.Players.Count, 2);
Assert.IsNotNull(b.Players.Where(x => x.Name.Equals("Cross")));
Assert.IsNotNull(b.Players.Where(x => x.Name.Equals("Nought")));
}
We now have to change our Player class to provide a constructor which gives the client code an opportunity to pass in the player name, and subsequently wire up the Name property to a backing store. We then have to adjust our TicTacToeBoard constructor to use this constructor to pass in the desired player names. The new Player class is below.
public class Player : IPlayer
{
public Player(string name)
{
Name = name;
}
private string _name;
public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}
}
And the updated constructor is below.
public TicTacToeBoard()
{
Rows = 3;
Columns = 3;
Players.Add(new Player("Nought"));
Players.Add(new Player("Cross"));
}
Finally our test passes.
Our Third Test – NUnit
The NUnit version of the test is below.
[Test]
public void BoardHasRightPlayersTest()
{
TicTacToeBoard b = new TicTacToeBoard();
Assert.That(b.Players.Count, Is.EqualTo(2));
Assert.That(b.Players, Has.Some.With.Property("Name").EqualTo("Nought"));
Assert.That(b.Players, Has.Some.With.Property("Name").EqualTo("Cross"));
}
Again, since we’ve done the work to augment our classes to make our test scenarios pass, this test passes as soon as its written.
Our Third Test Winner – NUnit
The NUnit version just reads better to me. My bias was clear above, but the fact that we have to crack open lambdas for a test this straightforward doesn’t bode well for when we get into more complicated scenarios down the road. NUnit’s fluent interface really starts paying off here, and things only get better in the next case.
Our Final Test – MSTest
Our final test will check for the case wher ewe try to make a move that is outside of the bounds of the board. The test is below.
[TestMethod]
[ExpectedException(typeof(ApplicationException))]
public void OutOfBoundsMoveThrowsExceptionTest()
{
TicTacToeBoard b = new TicTacToeBoard();
b.MakeMove(4, 3, null);
}
Note the use of the attribute to indicate that the test method will be throwing an exception. To get this working, we haveto implement the MakeMove method on our TicTacToeBoard class, as below.
public bool MakeMove(int x, int y, IPlayer mover)
{
if (x < 1
|| x > Rows
|| y < 1
|| y > Columns)
{
throw new ApplicationException("Move out of bounds");
}
return false;
}
Our Final Test – NUnit
Here’s where we really start to see the power of NUnit come into play as compared to MSTest.
[Test]
public void OutOfBoundsMoveThrowsExceptionTest()
{
TicTacToeBoard b = new TicTacToeBoard();
Assert.That(() => b.MakeMove(4, 3, null),
Throws.Exception.TypeOf<ApplicationException>()
.With.Message.Contains("Out of bounds"));
}
First off, no attributes; the meaning of the test is captured in the code. Next, we can check for the message that the exception throws back at us in addition to the exception type, which can be useful when we’re checking both for program correctness and display correctness.
Our Final Test Winner – NUnit
The clarity of the NUnit version in our final test beats the MSTest syntax hands down. Yes, you can extend MSTest such that you could write similar-looking tests when checking for exceptions, but again, we are reviewing out of the box implementations.
And The Winner Is…
NUnit, hands down. By the numbers above it’s actually a draw, given that both frameworks took two categories and tied on the other. But I feel that the overhead of an external application to run your tests and some additional up-front setup that will get rote-like after a few times is a small price to pay for more powerful assertions and a more legible and readable test style. Throw in TestDriven.NET, and it’s really no contest. I’m sure MSTest’s attraction could be upped with some third party add-ins as well, but when you’re having to load add-ins to increase readability vs. buying a tool to help you run your tests more efficiently, well…
So our shop will be staying with NUnit + TD.NET for a while. Let me know about yours in the comments.
[...] This post was mentioned on Twitter by YAMAMOTO, Yasuhiko, Jeff Vera. Jeff Vera said: Blogged: MSTest vs. NUnit with Visual Studio 2010 & TDD http://www.barebonescoder.com/2010/06/mstest-vs-nunit-with-visual-studio-2010-tdd/ [...]
There are a few more things I like about working with NUnit (and I don’t even like the fluent api):
1 – MSTests isn’t simple to get running in the CI server without VS installed there (Please don’t install VS in your CI server.) You need to hack around a bit to make it work, unless you’re using TFS Team Build.
2 – NUnit GUI has an option to automatically rerun the tests if the test assemblies are updated. So basically you can just keep writing tests and doing your refactor-fu until you see NUnit flash in you task bar.
3 – But I don’t really use NUnit GUI, I use R#, so I can also click on the error and jump to the method.
4 – And then there are a bunch of intangibles, like my preference toward OSS and dislike for airtight integration like the TFS stuff.
Totally agreed on the CI point. We use TeamCity for our CI server, and getting that to work with NUnit was cake. Good to know that it still takes some hacking to get MSTest to work there. Definitely another strike.
MSTest vs. NUnit with Visual Studio 2010 & TDD…
Thank you for submitting this cool story – Trackback from DotNetShoutout…
[...] MSTest vs. NUnit with Visual Studio 2010 & TDD – Jeff Vera explores the differences between NUnit and MSTest for unit testing in .NET, breaking the comparison down into a few stages, examining setup and a number of test cases and announcing the winner of the round at each stage. Check out the comments for some other good points from Sergio Pereira [...]
As a side, the nUnit calls can be wrapped in a facade so they can be run from within Visual Studio. I think it’s the unit tests in FluentNhibernate that have a really good example of doing this with extension methods. It eliminates the need of the nUnit GUI.
Also, ReSharper has the same ‘run unit test’ functionality. Well worth taking a look.
Nice article. I’m not sure I would come to the same conclusion (that NUnit wins, “hands down”), but the comparison is interesting nonetheless. I’ve used both NUnit and MS unit testing, and I felt they were quite comparable.
MS is a little unusual in its use of ExpectedException, but you can work around this (and check exception messages as well) by simply adding your own Throws() method to your test project: http://bit.ly/Xmn8q
What’s funny is that back when I started using NUnit on personal projects, it also used the attribute-based detection of exceptions. It really comes down to the fluent interface having won me over.
I personally use extension methods to mask my choice of framework when it comes to making assertions. So
someTestResult.ShouldEqual(thisExpectedValue);
could be implemented using whichever test framework you prefer to use.
For NUnit:
public static void ShouldEqual(this string actualValue, string expectedValue)
{
Assert.That(actualValue, Is.EqualTo(expectedValue));
}
For MSTest:
public static void ShouldEqual(this string actualValue, string expectedValue)
{
Assert.AreEqual(actualValue, expectedValue);
}
The choice of attributes on the classes and methods would give it away, of course, but it makes your tests a lot easier to move between frameworks (if that’s your idea of fun) and a lot easier to read.
[...] MSTest vs. NUnit with Visual Studio 2010 & TDD A comparison of two common .NET testing frameworks, showing their differences in facilitating unit testing. [...]
Thanks for the side-by-side comparison! I have been helping a friend with a hobby project in VS2010 Express and started looking into unit testing… I didn’t realize that MS started bundling their own version. I used NUnit 4-5 years ago (before fluent), so the MSTest interface looks very familiar. Is the fluent interface hard to learn? One thing I liked about the original NUnit interface was that it was pretty straightforward… Assert Expected = Actual, with a couple of special cases (ex. Null).
Once you get used to the fluent interface, you won’t look back. It’s really been a big determiner for us as far as staying with NUnit. Your tests will become much more expressive, and learning it starts making you think about what you’re asserting from a spoken word perspective as opposed to the old, terser syntax. I’ll post some side-by-side comparisons in the future so it’s clearer.
I would disagree with you on your points in “Our Third Test Winner – NUnit”. I believe that lambdas provide better support for refactoring and your unit tests will be updated if you decide to rename Name property to FirstName or Title or whatever. With nUnit’s way you will have to manually deal with strings. Have you ever heard a phrase ‘magic strings’? There is a reason why so many different frameworks move towards lambdas.
Why would you check for exception message? I’m sorry, but throwing ApplicationException and checking for it’s message is a smelly way to do so. Your exception should be specific to the issue you are experiencing, and throwing something too generic is a bad idea. The last thing I want in my code is to have a single catch clause and then do if..then..else or switch on a message.
What you don’t account for at all here is TFS and a lot of power that brings. If used wisely it can be a huge benefit for a small to decent side dev team(s) with loads of integrations for qa, project managers, etc.
In the end it doesn’t really matter which unit test framework you use as long as you use one and do so with some thinking.
P.S. I use both nUnit and MSTest at work and outside of it and I don’t think there is a huge difference in them in terms of unit testing.
P.P.S. Get yourself ReSharper. It will be a much better tool than TestDriven.Net plus you’ll get a lot of power with it.
I agree that lambdas are powerful and very useful tools, but power + utility != readability. One could definitely do additional work to make MSTest tests “read better” a la NUnit’s fluent interface, but I was focusing on out-of-the-box implementations.
The reason I (and my team at work) checks for exception messages is to tighten up the test and nail down what we expect to see in production scenarios when exceptions are thrown. The type of exception can definitely help narrow this down, but that will never help bring to light what a parameter value might have been that can be the difference between a five minute diagnosis and a thirty minute diagnosis.
Agreed on your point re: it doesn’t matter. It all boils down to context, your shop’s standards, and mutual consensus amongst the relevant members of your team.
We tried ReSharper and found it to be a memory hog. We settled on TD.NET + CodeRush, and frankly the clarion call of of lighter-weight editors (vim) is slowly starting to sound more compelling. We’ll see. Either way, good comments, and thanks for reading.
[...] we’ll be using the same example that we used when comparing MSTest to NUnit in Visual Studio in this post. We will also attempt to drive this with tests first, utilizing whatever keyboard shortcuts we can [...]
IMHO Quite a bit bias in the test selection also ..
The big win VS2010 is the autogeneration of classes when you write the test.
IMHO the syntactic difference is irelevant as i normally inisist on strongly typed tests its better when the code is changed.
Continious integration with MSTest is a pain and you basically want to use TFS then
You may consider looking at a small framework I created for exactly this purpose. It’s called Fluent Assertions, and provides a fluent API for verifying the outcome of your AAA or BDD-style tests. The one thing I personally like is the clearness of the messages it gives, essentially keeping you out of the debugger hell.
You can read more release 1.2 here:
http://www.dennisdoomen.net/2010/04/fluent-assertions-12-has-been-released.html
And you can download it from here:
http://fluentassertions.codeplex.com/
This looks pretty cool at first glance, will look at it more closely to see how we could leverage it on my team.
[...] Blog: MSTest vs. NUnit with Visual Studio 2010 & TDD [...]
Great overview. I do a lot of .NET work on Linux and Mac (so, Mono work I guess) so I use MonoDevelop quite a bit. It has NUnit support baked right into the IDE very much like MS Test does in Visual Studio. I guess I should consider myself lucky since this is the best of both worlds.
Interestingly, I was in a forum recently with one of the NUnit developers and he is switching over to MonoDevelop as his primary IDE. He is using MonoDevelop on Windows where it actually runs on .NET proper (not Mono) but with the multi-targeting ability it allows him to test against both .NET and Mono easily.
I didn’t realize that MonoDevelop had NUnit baked right now – will have to try that out to see what it’s like.
This reeks of bias. You downplay having to navigate to NUnit and open it and navigate to the binaries rather than having everything integrated, smear lambdas which make for easy refactoring (in favor of magic strings), and then make fun of attributes in favor of ridiculously verbose… lambdas (the same lambdas you just smeared). Obviously you’ve been working with NUnit longer and are just at home with its syntax.
NUnit hands down, and here’s why:
Test Management.
MSTest automatically runs tests when you start Debug mode, and NUnit presents it’s gui and then waits for you to hit Run Tests.
This pause allows you to select which tests to run, or which test groups to run very simply.
While this may not seem like much, try managing a test project with 750 tests that takes 20 mins to complete. You do not want to automatically start running all tests when you start Debugging.
While MSTest does allow to run specific tests, it is extremely frustrating and not at all intuitive.
Any thoughts ?
In our workflow, we don’t use the NUnit GUI. We use TestDriven.NET, which allows us to have context-based test running. We can run one test, we can run all the tests in a class, all the tests in a namespace/folder, and all the tests in a project, based on where we right click and select “Run Tests.” It’s smoother and more integrated than the NUnit GUI, and allows for debugging with a few less steps.
I kind of agree with Publius that this article seems a tad on the biased side. However as I have little knowledge of either framework I thank you for some useful insight.
I’m coming at it from the angle of needing to regression test SQL Server stored procedures after refactoring for performance, so I would be interested in any views or experience anyone may have here doing this with nUnit, MSTest or any other testing framework.
We also have some small VSTO and ASP.NET projects that perhaps could benefit from unit testing if perhaps not full on TDD.
Our needs boil down to:
1. Check multiple resultset data matches expected results
2. Report where the data differences are on failure (i.e. detailed diffing of sometimes large (200k rows) resultsets
3. Impersonate domain users for permissions testing (prob need to do this in SQL using EXECUTE AS?)
4. Parameterised / data driven tests. Many of our stored procs are quite flexible in that they have many parameters, so I would ideally need to have many different inputs tested for each one.
From what i’ve learnt reading on the web I think both NUnit and VS2010 will tick boxes 1 and 4, and box 3 I can tick by having pre and post test scripts create the neccessary SQL logins and users then use EXECUTE AS to run as different users in SQL.
Point 2 seems to be the most difficult, particularly for large resultsets as we could be talking several hundred MB of data to compare. I’ve seen NUnit examples where the test outputs to XML, then presumably you use the diff tool of your choice, can VS2010 do this too?
Any advice much appreciated, thanks
I was unable to create a test project (got an error message when I selected The Test Project Template with the Description Test Documents !).
But then I wrote Test in the top tight corner where it says
Up popped the template Test Project with the description Visual C#.
I selected this template and I got my test project.
Not entirely intuitive. But if it can help others !
How about mixing the two and getting the best out of both? Use MSTest attributes and run tests in Visual Studio, but stick to the NUnit asserts. I saw the idea here:
http://alsagile.com/archive/2010/03/09/stop-the-war-between-nunit-and-mstest-make-them.aspx
Any problem with this approach?
using NUnit.Framework;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Assert = NUnit.Framework.Assert;
… and done. You get the bleeding edge Assert you love with an interface for selecting and running tests that doesn’t look like it was made by a crazy person.
I realize this post was written months ago but if you’re pulling nUnit from Microsoft’s official NuGet repository, I’m not sure that MSTest still wins in the “environmental prep” category anymore.
Heh, good point. Check out the follow up article to this one, posted it relatively recently.
Hey, I have to agree that readability really has to be one of the most important things about writing unit tests. In an environment like mine that isn’t even enforcing TDD or unit testing, the next developer that comes along (assuming that they even run my unit tests), is going to spend about ten seconds trying to fix a broken unit test before commenting it out. If my test intention is hard to understand, it’s more than likely going to be removed or left broken. Having said that, though, we use MS Test in our environment because I can rely on every developer having it installed on his/her machine.
One more point: If your cursor is inside an MS test method and you want to run that particular test, put down that mouse! The shortcut is Ctrl + R, Ctrl + T (Run, Test). If your cursor is inside a test class but outside of any particular test method, the same shortcut will run all the tests in that test class. If you want to run the tests that failed during your last test run, you use Ctrl + R, Ctrl + F (Run, Failed). And Ctrl + R, Ctrl + A will run all tests in your test project. Absolutely essential if you’re doing TDD using MS Test.
Just wanted to say, what a great post!
At your suggestion I’ve been trying out TestDriven.Net and it is good but I’ve also found Visual NUnit 2010 which seems to do exactly what I want just that little bit better (IMO), best of all it’s free.
There are probably pluses and minuses for either tool but I thought I’d throw it into the mix
[...] http://www.barebonescoder.com/2010/06/mstest-vs-nunit-with-visual-studio-2010-tdd/ [...]
Guys, is very interesting your Article, and i have to say that having used both tools, i’m agree with you in the chosen winner if we only see the test framework without complementary features.If we include Code Coverage or Test impact that are out of the box features in the analysis i think that the result is different.
Very Good article – really helped me in putting TDD into practice. One Thing I noticed is that I had to adjust the third test as MSTest passed it from the start when the implementation is not present. The modified version broken down into 2 lines is like this:
[TestMethod]
public void BoardHasRightPlayersTest()
{
TicTacToeBoard b = new TicTacToeBoard();
Assert.AreEqual(b.Players.Count, 2);
var player1 = b.Players.Where( x => x.Name.Equals(“Cross”));
Assert.IsNotNull(player1.Count());
….
Folks!
I am trying to write NUnit tests in VS2010 and aim to run them on Mono..i am a Mac/Mono Noob, so trying to find some steps to run such tests on Mac, after deploying those ready-to be run tests on Mono. Any pointers?
I see that some people suggested to use the Nunit Assert library with the MsTest test runner. They refer to a post I made a while back.
I have never written a sequel to that. But I now use a fantastic assertion library instead : fluent assertions.
it’s available as a nuget, it is very actively maintained and develop. And it has some really nice construct and assert helpers.
Check it out, I am personally sold.
http://fluentassertions.codeplex.com/documentation
I also like the idea of using a different assertion library than the test runners because it binds me less to one testing framework, but that is really details. how often do you change the testing framework.
1 cheese
A cool MSTest feature not mentionned, data driven tests:
For example -
[DataSource("Microsoft.VisualStudio.TestTools.DataSource.XML", "|DataDirectory|\\MyTestCase.xml", "CASE", DataAccessMethod.Sequential)]