I’m not overly fond of the MS Test framework for unit testing, but it’s what we’re stuck with I mean using so I’m pressing on with it. The test manager makes it difficult to organize and run tests, and I greatly dislike how slow it is.
Today I’ve found some other friction in MS Test that’s even more of a PITA: External items aren’t copied to the test output directory unless you jump through several other hoops.
My current test environment uses a number of XML and HTML files as input and reference data. I keep those files in a folder separate from my test classes since they’re used by a number of different test projects. I use Add -> Existing Items and add those items as links to the various projects — and then set “Copy to Output Directory” to “Copy if newer” to ensure things get dragged over as appropriate.
This works just fine using TestDriven.NET to run tests; however, MS Test adds some additional complexity in order to get such items over to the test folder. Instead of relying on the “Copy to Output Directory” property, you’ll need to specifically call out the items via one of two methods: the DeploymentItem attribute or by specifically adding those items in to your test run configuration.
The DeploymentItem attribute looks like this:
[DeploymentItem(@"C:\vsprojects\MyProject\Tests\Test Support\XmlContentFileOne.xml")]
Unfortunately it didn’t work when added to a ClassInitialize setup method, so I turned to the test run configuration’s Deployment tab where you can add files or directories to carry over to the test run output folder.
Irritating, overly complex, and an additional layer of brittleness should I need to change anything. -1 (again) for MS Test.
9 comments:
I'm not sure how that's any more brittle than using the DeploymentItem attribute. If you're external file isn't there, then that doesn't help you. Instead, what you could do is make external files embedded resources within your test project and then you'll always know it's available during test execution.
My "brittle" comment was about the mess of having to separately mark out things which get copied over during a "normal" build process. It's more brittle than usual because I have to handle that in two separate places.
I don't understand why they need to handle that differently for MS Test.
I feel your pain Jim. My company shelled out the big bucks for VSTS. I've abandoned the MS Test structure for it's slow speed and lack of support of other UnitTest frameworks.
Long Live TestDriven.NET!!!
However I do like MS's boiler plate test generation. I'm hoping Jay Flowers' "Doubler" reflector add-in will be just as good, if not better. (Once I get around to learning it.)
Templates for test generation are a good thing. You should also look at Scott Bellware's NUnit Snippets (http://shrinkster.com/q7y) or make use of templates in ReSharper or other similar tools.
I've been of a mind to port Bellware's NUnit snippets over to MS Test, but haven't gotten around to it...
In addition to being slow I hated how MS Test evaluated coverage. It seemed like you'd have an if statement 'or-ed' with two expressions. And it wouldn't give you coverage for the line at all, even if you were hitting the if statements in all cases. There are tons of classes in my project that were sitting at ~97.2 coverage, when it should be %100
You can also just add the DeploymentItem attribute to the TestClass:
[TestClass]
[DeploymentItem(@"C:\vsprojects\MyProject\Tests\Test Support\XmlContentFileOne.xml")]
public class ....
That last one was what I needed... seems so hard to find useful documentation for this product.
I know this is a little off topic here but does anyone know how to remove the folders that I assume mstest is making in my project folder when running telerik ui tests with CCNet? the folder name looks like this
devapps_BIZ-DEVBUILD 2011-10-11 17_45_20
Post a Comment