We are thinking about moving our tests from MSTest to XUnit.
Is there any migration application that takes a MSTest and migrates it to XUnit?
Also, if not, what should I look out for when doing this?
Thanks. JD.
@JD - note that it would be simpler to move from MSTest to either NUnit or MbUnit, as Mr. Chaliy's link clearly shows. If your primary goal is to migrate away from MSTest, those may be better choices. If you agree with the xUnit.net philosophy, never mind. :)
TrueWill
2009-11-17 18:33:58
@TrueWill: While I wouldn't be standing around saying "What's wrong with MSTest", I'd see a move to NUnit or MbUnit as a sideways move - at the end of the day MSTest has pretty much got a one-to-one mapping to NUnit and you havent gained much, except for lots of MbUnit Attributes (if you consider that a 'gain').
Ruben Bartelink
2009-11-18 09:01:25
Thanks guys,As I mentioned below, I have not used xUnit before and migrating 500 tests may be too much of a task. I will move to NUnit for now and then hopefully on new projects look into the xUnit philosphy.
JD
2009-11-18 11:03:30
@JD: You could give it a try on a subset and see how it goes. What are the key things you feel you're going to gain by porting to NUnit? IOW How do you justify the time on that porting process? To me MSTest and NUnit are not dramatically different (though in a straight fight I know which one I'd pick)?
Ruben Bartelink
2009-11-18 11:24:13
+1
A:
I moved quite a few tests recently. It depends on how many and what type of tests you're converting, and you didnt kill yourself giving us details. In general, I think its safe to assume that your average MSTest minded shop wont be massively Test Infected and thus wont have delved into each dark corner of MSTest.
All the Assert.* methods and the basic Test Attributes are simple find and replaces. The more rare ones, I'd generally steer towards assessing each case individually. Unless you're already a xUnit.net expert, you've got lots to learn and this will help you.
Also, usage of Assert.Fail isnt a simple transformation. The other thing is the transformation of TestClassInitialize to IUseFixture - simple to do, but hard to automate.
If people are using Test References, you won't be able to remove the reference to the MSTest assembly (and you'll still need to have VS on your build server - and it will continue to randomly fail on the Shadow taks, see my questions).
The biggest manual work for me was going through the 20 lines of boilerplate in a region at the top to see whether anyone actually used any of the custom attributes before deleting them.
The main thing that would have been a lot of work had it not been for a CodeRush template was converting ExpectedException to Assert.Throws. If you havent got CodeRush or ReSharper on this job, you'd be stealing money from your employer.
Ruben Bartelink
2009-11-18 09:14:27
We have around 500 tests over about 200 files. I have not used XUnit before, I just saw some good reviews on it and the fact that XUnit is created by the NUnit developers, I thought that would be the way to go. Since I only wrote a few of the tests, I do not have all the details of all the other tests.
JD
2009-11-18 11:00:28
@JD: xUnit.net is definitely worth it in my experience - it makes you write better, shorter, cleaner tests. If you read Osherove's book and xUnit Test Patterns you'll appreciate it even more over the other frameworks. I've had only good experiences in my interactions with the team too (in terms of response to requests being sensible, timely etc.). 500 tests is in the realm of what I moved. What are you planning for runners etc.? @Others: Anyone else got porting experiences/pitfalls?
Ruben Bartelink
2009-11-18 11:15:30
@Ruben. Thanks. The idea is to incorporate the tests into CruiseControl (msTest would have required installing VS and we did not want to do that). We have resharper on our development machines. I will definately look at xUnit over the next few weeks. Can you recommend any good tutorial/vids etc. Thanks once again.
JD
2009-11-18 12:43:13
@JD: Be sure you dont have Test References (Private Accessors) before you switch to NUnit if you dont want a VD dependency. I find the articles at http://xunit.codeplex.com/#blog to be the best learning resource - you'll find something that suits your learning style. In general, the source and the samples are enough though - they're small and neat. If you're budgeting more than a day for porting to NUnit, you need to figure out whether all you're doing is getting over an unclean feeling to install VS on your CI server- remember there's a separate 'MSTest' install package for CI servers in 2010
Ruben Bartelink
2009-11-18 13:17:29
@JD: Team System Test in 2005 introduced Private Accessors/Test References. This technology is referenced [IMO] in caps in http://www.codethinked.com/post/2009/11/05/Ite28099s-Okay-To-Write-Unit-Tests.aspx. It uses a MsBuild Task called Shadow which calls an exe called publicize.exe which produces an assembly containing ClassName_Acessor classes with methods that can invoke private methods in an assembly using reflection. If people have used that, you'll know by Find-in-Files for '_Accessor' or by seeing Test References folders in your test projects.
Ruben Bartelink
2009-11-18 15:18:53
In my case, they were used so I sadly have VS on my build server (and publicize.exe regularly makes my build fail only to work when retried.) (TMI: I'm in the process of routing around this issue by using a Test Stripper)
Ruben Bartelink
2009-11-18 15:20:29