Take the 2-minute tour ×

I've recently started with a new firm and I'm trying to understand the mechanics behind something, so I'll anonymize the code and present but a sample:

[Test(Description = "Retreives the New view for XXXX.")]
public void New()
  "~/XXXX/New".ShouldMapTo<XXXXController>(x => x.New());
  "~/XXXX/New".WithMethod(HttpVerbs.Post).ShouldMapTo<XXXXController>(x => x.New(null));

and again:

[Test(Description = "Test the model injection into the New view.")]
public void New()
  var @new = WXYZController.New();

  Assert.IsInstanceOf<WXYZSettingsModel>(@new.ViewData.Model, "Expected the data model to be of type WXYZSettingsModel, but the model was another type.");
  var model = @new.ViewData.Model as WXYZSettingsModel;
  if (model == null)
    Assert.Fail("Failed to cast data model to type WXYZSettingsModel.");

    Assert.IsNotNull(model.YYYY, "Expected an instantiated service message, but a null message was returned.");
    Assert.AreEqual(model.YYYY.Status, WXYZ.Success, "Expected a success status code, but another code was returned.");
    Assert.IsNotNull(model.Categories, "");
    Assert.AreEqual(model.ZZZZ.Status, ABCD.Success, "Expected a success status code, but another code was returned.");

It seems to me this violates the purpose of unit-testing, as you should never unit-test the framework, but rather, your own code, right? Did someone just get carried away?

Or am I missing some fundamental component of this code that is just obvious to someone who is more familiar with unit testing.

Note that there are entire files (one of each of the above per controller) that never test a single line of internal code, but are filled with these tests. Even to the point of this is fairly boilerplate now that I've anonymized it.

If we were instead testing like this (pseudocode now)

[Test(Description = "thingy tester, duh")]
public void ThingTest(){
  var mock = new MyDataMock();
  var finalMock = new MyFinalMock();
  var controller = new thingController();

  var test = controller.Thing(mock);
  assert.AreNotEqual(test,mock,"It didn't change it");
  assert.AreEqual(test,finalMock,"It worked!");

I would expect that to be what the unit tests I should see should look like, no?

share|improve this question
It looks like that code is testing the routing rules, defined by the web app, not the framework? As such, it's really testing app behavior. –  Max Dec 20 '12 at 19:42
I ran it by several of my friends, and they didn't understand it either. I can understand the routing code, but the other example, where it tests that it got a base new model? –  jcolebrand Dec 20 '12 at 19:52

1 Answer 1

There are cases when you might want to sanity check the framework's fitness that you're working with, especially in a regulated environment.

For example, in medical software development, if you follow the standard IEC 62304, the use of Software Of Unknown Providence (SOUP) is a risk (using third-party frameworks like ASP.NET MVC Framework or even the .NET Framework is considered risky under the standard). Depending on the Class of the software (A, B, or C), you may have certain burdens laid upon you to assess the risks that SOUP brings to your software system. One way to do this is to perform black-box unit and integration testing of the functions you intend to use in your software system, to verify they they work correctly for your purposes. If you follow IEC 62304, you're technically on the hook for any compiler you use, let alone 3rd-party components or frameworks you might decide to use.

Ultimately, if your software and process is audited by the FDA or a third-party, you have to be able to show to these auditors that you took reasonable steps to validate SOUP components, so you might have tests like these.

share|improve this answer
To be more precise, you are responsible for any SOUP regardless of what standard you follow, as an FDA or third party auditor will definitely consider on the hook for it. You don't need to be following IEC 62304 to be responsible for SOUP, its just a lot clearer about validation in the standard when you do. –  CokoBWare Dec 22 '12 at 15:21

Your Answer


