Unit Testing in Whidbey - some pointers for improvement
Jim Newkirk - apparently the guy in charge of all the Unit Testing stuff in VS Team System, and the guy who co-wrote
Nunit, shows us a new object in the Unit Testing Framework of VSTS(Team system) -
PrivateObject.
The whole idea behind the object is that you can Test Private methods inside your tested class. So what happens is that when you auto-generate unit tests, and you have a TestClass.PrivateMethod() - You will automatically get a class that
inherits from PrivateObject, which exposes all the private methods as well, as if they were public, essentially calling PrivateObject.Invoke(“MyPrivateMethodName“) underneath the covers. Think “Web Service Proxies“, only different :)
What I like about this is that it's a very elegant solution to an age old problem - How do you test Private methods without “exposing“ them as public? (the question of whether you should even test private methods at all is in itself a matter of religion. Think VB vs. C#, only different :) )
Anyway - that's cool. Kudos. I like the fact that if I
wanted to I could do it. But now, for some more pressing matters.
I have a couple of points to make about Unit Testing in Whidbey:
- I want to do a simple Red-Green-Refactor cycle. Why can't I do that in the simplest way possible? The simplest way for me would be to:
- Create a test project (not from the wizard! I don't want to do load testing, ugh. I just want to build a class, got it?)
- Create a test that does not even compile
- Make it compile by adding a new Tested Project
- Make the test compile and fail (this is where you get stuck)
- Like I said - the last stage can't be done this simple because:
- You can't run your unit tests unless you have specified a Test Configuration scheme. So:
- Now I need to add another test project which will automatically contain a test configuration scheme (yep - that's the only way to do it. I asked Jim)
- now you can run your tests. ugh.
- Like Peter Provost wrote - it would be nice to have auto-creation of non existing classes, not just non-existing methods.
- I want to be able to just add a test class to any project, not just a test project.
- What's with the Assert.Inconclusive? It either fails or it passes, right? Assert.Inconclusive == Fail
Otherwise I love some of the newer stuff, like the fact that you have an object test bed - You can right click on a class and instantiate that object using dialog provided parameters. (this is all in design time). Then you have this object sitting there and you can invoke its methods by right click on it's icon. You can debug into the source code too. Much like what the amazing NUnit-Addin has done for me in the past (and probably well into the future).
I'd love to see Ad-hoc debugging a-la Nunit-Addin style. That would be awesome.
Great job guys - but still needs some major polish until I could work with it as smoothly as I can with NUnit and NUnit-Add-in today.