views:

430

answers:

2

Hi,

We have been creating silverlight unit tests by creating a plain vanilla .net unit test project, removing all references except for the unittestframework one, and then adding references to the SL assemblies we need (system, System.Core, ...). For more information, look at this blog post. We can do this, as we are adhering to the MVVM pattern and have close to no code in the codebehind. We are not testing the view, but the functionality in all the layers behind (VM-M basically).

Now, this allows us to test the silverlight logic in our team build every night. This works pretty well, until we start mixing SL projects and normal .NET projects. When we select all SL unit tests and run them, they pass. The same goes for the .NET unit tests. When we run them all at once however, either one set or the other fail completely. The message we are seeing states : "Unit Test Adapter threw exception: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information..". I guess the issue is that these two sets of tests are using different system assemblies, but I haven't been able to pinpoint the problem.

Has anyone tried this? Cheers, Phil

A: 

Hi, I'm guessing that there are issues with having multiple System, mscorlib, etc. libraries in the app domain that probably confuse the test execution environment.

Can you separate this into multiple test runs for the TFS build, OR perhaps author an msbuild script with code to call mstest.exe for one of them and get results that way?

Jeff Wilcox
Thanks Jeff, we solved it by calling mstest.exe in our build script twice (once for .NET tests, once for Silverlight tests).
Phil
+1  A: 

How about using two separate build definitions? They can both be triggered the same way or at the same time. The only difference is that you have references to just the SL projects in one and just the .NET projects in another.

If you didn't want to reference the projects from the build definition you could create a couple of solutions to use with your builds and reference only the SL projects in one solution and just the .Net projects in another.

Ryan Pedersen