This project is read-only.

Support for Visual Studio Unit Testing Framework

Apr 25, 2012 at 1:29 AM

If we were to add support for the Visual Studio Unit Testing Framework, how should we name the new project?

  • AutoFixture.MSTest 
  • AutoFixture.VisualStudioUnitTestFramework

This is particularly for adding support for the DataSourceAttribute class. 

Apr 25, 2012 at 7:33 AM

I'd prefer AutoFixture.MSTest. The other might be more officially correct, but 'everyone' knows what MSTest is, so I think it communicates intent better and faster.

Jun 3, 2013 at 7:53 AM
What is the state of specific support for MsTest with AutoFixture? I was just about to start using AutoFixture, as I noticed that there is specific support for RhinoMocks. Then I discovered that AutoDataAttribute is not there for MsTest, only for xUnit.

I know that the core of AutoFixture does not depend on any unit test framework, but without auto-mocking I am not convinced that we should start using AutoFixture.
Jun 3, 2013 at 8:13 AM
AutoFixture currently has Auto-Mocking support using four different Dynamic Mocking libraries.
  • Moq
  • FakeItEasy
  • NSubstitute
  • Rhino Mocks
That capability is completely decoupled from any unit testing framework extensions, so you could use any of those four with MSTest.

However, only provides an extensibility model that enables the addition of something like the [AutoData] attribute. MSTest and NUnit are too hard to extend (if it's at all possible), so there are no [AutoData] equivalents for neither MSTest nor NUnit. Preliminary research indicates that it's not possible to add this capability because of the constraints posed by those two unit testing frameworks.

However, in case I'm mistaken, I don't mind having that pointed out to me.
Jun 3, 2013 at 8:26 AM
Some notes from the past research:

As of Visual Studio 2010, the extensibility points were:
Basically, one could use the [DataSource] attribute on a test method. Inside that test method then, one could do this:
new Fixture().Customize(new MSTestCustomization(this.TestContext));
AutoFixture could inspect the TestContext in order to use the TestContext's DataRow property (to get the values). For this to work, the class property names should match the DataRow names.

An alternative way could be setting the ProviderInvariantName property to the name of a custom ODBC driver.

Finally, all the above should be compatible with the Microsoft.VisualStudio.QualityTools.UnitTestFramework assembly which might be different across Visual Studio versions.
Jun 3, 2013 at 11:33 AM
Thanks for the quick answers. I realize that MsTest is way too primitive when it comes to extensibility. Alas, I am probably stuck with it for now. I am not too fund of the [DataSource] approach - putting unit test input values in a SQL database - so I don't think I will go this way.

I will reply again if I find my way of using AutoFixture with MsTest.