Thanks… Definitely another gotcha.

Ade

Example:
[TestClass]
[DeploymentItem("MyFolder\MyTestFile.dat")]
public class MyTest
.
.
.

Did you see it? The developer forgot the @ before the string! So that \M produces a special ASCII character!

If you do this, you will get the following error on every method in the test class:
UTA004: Illegal use of attribute on methodname. The TestMethodAttribute can be defined only inside a class marked with the TestClass attribute.

[...] Miller wrote a good article on some of the gotchas of using the DeploymentItem attribute. The article is a good read and addresses handling deployment [...]

I think the order is based on how reflection returns the methods and classes. I never investigated this as I never rely on this – it’s an anti-pattern to expect tests to run in the same order or rely on ordering.

Ade

was looking at a legacy MSTest project. The tests were always running in the same order. The order was not alphabetic and was bouncing between methods in two *.cs TestMethod files.

I did not change the physical order of the legacy code. I did for my convenience append “MSTest01″ to the method name of the first test, “MSTest02″ to the method name of the second test, et cetera.

To my surprise, the execution order of the TestMethod functions changed; #3 first, #6 second, #5 third, et cetera.

When I removed the “MSTestnn” strings from the TestMethod function names, their execution order changed back to the previous ordering, i.e., one test from the first .cs file, two tests from the second .cs file, five tests from the first .cs file, et cetera.

It seems that file location may not be a factor while TestMethod function name may be a factor.

http://stackoverflow.com/questions/2255284/how-does-mstest-determine-the-order-in-which-to-run-test-methods

[P.S.: I appreciate you sharing your MSTest tips. Have you looked at xUnit.net?]

Process monitor is very noisy but the filter feature will let you cut down the output. I’d try setting a filter on the Process Name to exclude everything but MSTEST.EXE.

Ade

I’ve gotten past the issue of #including “afxwin.h” and I can get the unit tests to run fine through the IDE. When I run it using mstest.exe though, the tests hang while loading the unit test DLL. I believe this is because it is missing a DeploymentItem, although there are no external files that the tests rely upon.

This only starts to happen when I call AfxGetApp() and also AFX_MANAGE_STATE, of which I’m not sure which one is causing the issue.

My guess is that it is looking for an MFC DLL. Is there any way that you can have mstest or another tool tell you what items it is looking for?

I have tried Process Monitor but there are so many calls it gets overwhelming trying to find the missing DLL.

Thanks in advance,
Jared

MSTest creates a TRX file. This is unfortunately in a proprietary format although you can convert it with this tool.

The hang when including afxwin.h might be due to the not being able to load another dependent library. I’ve seen similar behavior with WinSxS and OpenMP libraries (see this post). I see you posted on stack overflow, which is probably a better place to get an answer for this. SxS load errors appear in the event log so that’s a good place to look to see what’s wrong also.

Ade

I’m having a problem when I #include “afxwin.h”. The solution builds and then when it gets to running the tests, the first test will hang and no other tests will run. If I comment out the #include, then the tests will run fine.

My compiler options are /clr, /mTd and I’m compiling to an MFC shared dll.

[...] I was testing the behavior of MSTest’s DeploymentItem attribute I relied on fact that MSTest executes tests in a predictable order to figure out how the attribute [...]