Does anyone really successfully use MSTest throughout the team?

Question

I have used MSTest so far for my unit tests and found that sometimes this randomly interrupts my builds for no reason. The build will fail in VS, but compiling it in MSBuild - with an error such as "option strict", does not allow IFoo to use the IFoo type. I believe I finally fixed it, but after the error came back and struggled to get her to leave again and a little help from MS, I still had a bad taste in my mouth. I also noticed that looking at this forum and other blogs and such that most people use NUnit, xUnit or MBUnit .. We are on BTW at VS2008 .. So now I am looking to explore other options.

I am working on promoting our team to start doing TDD and real unit testing and plan some training, but first I would like to offer a set of standard tools and best practices. To this end, I searched online to create a suitable infrastructure for the build server and dev machines ... I looked at typemock as I heard great things about their mocking structure and noticed that they seemed to promote MSTest and even have some links people moving TO MSTest from NUnit .

This makes me rethink my decision .. so I think I ask: does anyone use MSTest as part of their TDD infrastructure? Any known limitations that it has if I want to integrate with the collector / CI server or code coverage or any other type of TDD tool that I may need? I searched these forums and basically found that people are comparing third-party structures with each of the parties and do not even give MSTest much of a chance ... Is there a good reason why ..?

thanks for the advice

EDIT: Thanks to the answers in this thread, I confirmed that MSTest works for my purposes and skillfully combines with CI tools and build servers.

But does anyone have any experience with FinalBuilder? This is a tool that I would like to use for build scripts so as not to write a ton of XML compared to other build tools. Any limitations here that I should know about before moving on to MS testing?

I should also note that we use VSS = (. I hope that we can do this in the near future - I hope that part of the first, perhaps even the first step, will allow you to configure all this infrastructure.

Answer 1

At Safewhere , we are currently using MSTest for TDD, and it is working fine.

Personally, I like the integration of the IDE , but I don't like the API. If it ever becomes possible to integrate xUnit.NET with the VS test runner, we will begin to migrate soon.

At least with TFS, MSTest works very well, as part of our CI.

In general, I believe that MSTest works adequately for me, but I do not cling to it.

If you are evaluating library layouts, check out this comparison .

Answer 2

I use MS Test since VS 2008 came out, but I didn’t succeed with a power weapon like TDD or CI here at work, although I did a little work with Cruise Control in an attempt to build a CI server in my local field.

In general, I found that MS Test is pretty decent for testing locally, but there are some pain points for institutional use.

Firstly, MS Test adds a lot of things that probably do not belong to the source of control. .VSMDI files are particularly annoying; just running MS Test creates 1 to 5 of them and adds them to the solution file. This means that you give up your .SLN in source control, and this kind of outflow is bad.

I understand the supposed moment behind these additional files - tracking startup history, etc., but I do not find them particularly useful for anything but one developer. You should use your build service and CI for this kind of thing!

Secondly, you must either have Team Foundation Server to run your unit tests as part of CI, or you need to have a copy of Visual Studio installed on your build server if you are using, for example, Cruise Control.NET. See this stack overflow question for more details.

In general, there is nothing wrong with MS Test. But the CI transition will not be as smooth as it can be.

Answer 3

I have very successfully used MSTest in our company. We are currently creating standardized assembly processes in our company, and so far we have had good success with TeamCity. For continuous integration, we use TeamCity configurations. For actual releases, we create large msbuild scripts that automate the whole process.

I really like mstest because of the integration of the IDE, and also that all of our developers can automatically use it without installing any third-party dependencies. I would not recommend switching just because of the problem you are having. I came full circle where we went to nunit and then returned again. This framework is all the same at the end of the day, so choose the one that is easiest for your developers to access and start using.

I suspect that your problem may be ... it sounds like an unclear problem that I encountered earlier, where there are incorrect links to the DLL (for example: adding explicit links (via viewing) to projects in your solution, and not using project links) leads to obsolete problems that only occur after clean inspections or assemblies.

Another really suspicious problem that I discovered earlier is if you have some kind of visual component or control that has a public property of some kind of custom type that is serialized in a .resx file. I usually need to mark them with an attribute that says SerializationVisibility.Hidden. This means that the IDE will not try to create setters for the property value (which is usually some kind of object graph). Just a thought. There may be a way out.

I trust the tools, and they really don't lie about the real problem. They only distort them or report them as something completely obscure. It sounds like you have it. I suspect this because the error message does not make sense if everything is in order, but it makes sense if some part of the code downloaded an outdated or modified version of the DLL at this point.

Answer 4

I successfully deployed several FinalBuilder installations and the clients were very pleased with the result. I can highly recommend it.