Why is testing MVC Views frowned upon?

Question

I'm currently setting the groundwork for an ASP.Net MVC application and I'm looking into what sort of unit-tests I should be prepared to write. I've seen in multiple places people essentially saying 'don't bother testing your views, there's no logic and it's trivial and will be covered by an integration test'.

I don't understand how this has become the accepted wisdom. Integration tests serve an entirely different purpose than unit tests. If I break something, I don't want to know a half-hour later when my integration tests break, I want to know immediately.

Sample Scenario : Lets say we're dealing with a standard CRUD app with a Customer entity. The customer has a name and an address. At each level of testing, I want to verify that the Customer retrieval logic gets both the name and the address properly.

To unit-test the repository, I write an integration test to hit the database. To unit-test the business rules, I mock out the repository, feed the business rules appropriate data, and verify my expected results are returned.

What I'd like to do : To unit-test the UI, I mock out the business rules, setup my expected customer instance, render the view, and verify that the view contains the appropriate values for the instance I specified.

What I'm stuck doing : To unit-test the repository, I write an integration test, setup an appropriate login, create the required data in the database, open a browser, navigate to the customer, and verify the resulting page contains the appropriate values for the instance I specified.

I realize that there is overlap between the two scenarios discussed above, but the key difference it time and effort required to setup and execute the tests.

If I (or another dev) removes the address field from the view, I don't want to wait for the integration test to discover this. I want is discovered and flagged in a unit-test that gets multiple times daily.

I get the feeling that I'm just not grasping some key concept. Can someone explain why wanting immediate test feedback on the validity of an MVC view is a bad thing? (or if not bad, then not the expected way to get said feedback)

Answer 1

Simple UI testing is easy enough in ASP.NET MVC. Essentially all you have to do is assert that the returned HTML contains the elements you need. While this ensures that the HTML page is structured the way you expect, it doesn't fully test the UI.

Proper web UI testing requires a tool like Selenium that will use browsers on your machine and ensure that the JavaScript and HTML are working properly in all browsers. Selenium does have a client/server model so that you can have a set of virtual machines with Unix, Mac, and Windows clients and the set of browsers common to those environements.

Now, a well designed MVC (pattern, not framework) application puts the important logic in the models and controllers. In short, the functionality of the application is tested when you test those two aspects. Views tend to only have display logic and are easily checked with visual inspection. Due to the thin processing in the view and the bulk of the application being well tested, many people don't think that the pain of testing the view layer outweighs the benefit gained by it.

That said, MVC does have some nice facilities to check the DOM returned by the request. That reduces the pain quite a bit for testing the view layer.

Answer 2

I wouldn't say it's frowned upon. Rather, that sentiment is the result of the fact that unit-testing MVC views (at least of the aspx variety) is quite hard because aspx views have too much dependency on WebForms, which are themselves quite untestable. So the argument goes that it's not worth the effort because the views tend to be not that complicated.

Of course views can get quite complicated so it's your choice.

Answer 3

I'm not sure that it is frowned upon. Testability is one of the key benefits of using ASP.NET MVC. Check out Steve Sanderson's blog for more info on this.

He also wrote the hands-down, best ASP.MVC book (IMO) out there. Not only does he teach MVC, but he goes above and beyond to teach best practices around it, including testing practices.

I'm thinking I need to clarify a bit on unit testing views -- you can build unit tests around the result returned from the controller (ActionResult, etc.). You'll still need to do other testing for the actual UI and UI interaction.

Answer 4

You can learn how to test the View returned by a controller action, how to test the View Data returned by a controller action, and how to test whether or not one controller action redirects you to a second controller action by check out the following URL, describe in this brief article about Testing View Data in MVC.

Answer 5

Short Answer

Unit tests cannot guarantee that no one will change the source code. That is not what they are for. They should depend on input ( or no input in some cases), and outcome. This also has to be deterministic. Please note to unit test a non-deterministic piece of code, one must create mocks to make it appear as deterministic.

The unit test you are asking for, as I will explain below in this answer, is to guarantee no one will change the source code; which of course is not possible.

Long Answer

Imagine you wrote an application that takes an input and puts double quotes around it. For example, you give it Test and it returns "Test". To unit test that, you may write a few tests like below:

TestNoSpace
Test With a Space
Test With "Quotes"

You run your tests, and the expected output matches. Ok great! That will work that way for as long as no one changes the source code. If they change the source code but change only the structure of the source code, the tests will pass. If they change it, refactor it, the output will still be the same and you don't really care if they refactor it (change the structure) for as long as the output is the same. The tests will fail though if someone changed it from adding quotes to adding single quotes. Pretty trivial points we can agree on.

Now let's go to your question about testing MVC Views. That same idea applies, that given a certain input, you expect a certain output. For example, you may have a view:

<label>First Name:</label><Label>@Model.FirstName</Label>

Is that the input or the output? It is neither. It is source code. Similar to code you wrote for adding quotes which may look like:

public string AddQuotes(string value)
{
    return "\"" + value + "\"";
}

You would never write a unit test to make sure no one changes the above code, would you? You only would write a test to make sure that it behaves correctly: Given a string, it returns the string with quotes around it.

So now I ask you the same question: Why would you write a test to make sure no one changes the structure of the cshtml code?

You may say I don't care if the structure of cshtml code is changed, I just want to make sure the Model.FirstName is put in the correct place. Well, again, how would someone do that? Because the only way I can think for someone doing that is to change the structure of cshtml code, nonetheless, it is change to the source code.

At this point you may ask, "OK fine! But what if I wanted to test that given the current source code in cshtml, I expect a certain output by the Razor engine?" And the answer to that is: Do you have a doubt that Razor has a bug and you want to ensure it does things correctly? In other words, you would be unit testing Razor; which is obviously not something you are after or something one would do--unless, of course, one is building the Razor engine. You may still say, "I don't care if the label is moved down and more elements are added, I just want to make sure the Model.FirstName is mapped to the correct element". And to that I will say: What if the developer changed it from a label to a span or an input, now what? You see where I am going with this.

If you pay close attention, the cshtml is input for Razor engine. Testing to make sure cshtml is not changed would be the same as if you wrote a test to make sure no one changes an input to the AddQuotes method above: It just makes no sense.

So again, the question comes down to this:

1. What is it that you want to test?
2. What is the input?
3. What is the expected outcome?
4. Give an input, can we deterministically expect an outcome?

The answer to the above questions would be:

1. I want to test that the Model.FirstName is always mapped to the correct label.
2. I, yes I am talking about myself, honestly don't know. Is it the Model you pass to the view? If yes, you can unit test that at the controller to make sure the Model being passed is correct. Is it the CSHTML file? But that is source code that is passed as input to Razor and we would not test Razor as I have already explained above.
3. I, yes I am talking about myself, honestly don't know. Is it the _Layout.cshtml plus the cshtml file in question plus the inline JavaScript and CSS? What is it?
4. Well we cannot answer this unless we can answer 2 & 3 above.

Therefore, testing such stuff in the UI, not all stuff in the UI (some can be unit tested, see below), is not only frowned upon, but it just does not make sense; at least it is not a good idea. The cshtml file is source code and it makes no sense to write unit tests to make sure no one changes the source code.

OK, so we should not test UI?

No, that is absolutely not what I am saying! I am saying we cannot test that a certain field is mapped to the correct element in cshtml or any other UI because that depends on the structure of the source code.

You should test the behavior of UI using something like https://www.selenium.dev/ to ensure when things are clicked, it behaves properly or whatever other tests you deem fit.