> So what I had in mind was testing all the data's rendered correctly - Release date, Display 
> date, Type, Organisation, Topic, etc. This way we get a sort of mini-integration test 
> covering the whole view at very little additional cost.

@GrouchPotato I think you're making the assumption here that the main cost of a test is the execution time it takes when the test is run (either by a developer or on a CI server). 

> I know it's not so important for a simple admin view like that but given you're rendering the template anyway, why not have it?

Developer time generally costs much more than CPU cycles. Consider these factors:

**The time a developer spends reading a test case**. When working on an unfamiliar piece of code, you'll read relevant tests to make sure you understand all of the nuances of the functionality, or to decide where to add or change tests.

The time that takes depends on how many tests there are and how easy they are to understand and make sense of. In other words, if the tests are optimised for readability, skimmability and ease of comprehension then that will save developer time, ie money, in the medium term. There's a good [discussion about this on the software craftmanship list](https://groups.google.com/d/msg/software_craftsmanship/YRUAFCANDMw/zo-CpVulZQAJ)

Adding checks that all of the various fields are displayed correctly adds clutter to the test, making the test harder to read. The likelihood of a 'missing field' error is relatively low (consider the types of edits a developer will likely make in the future), and the cost of such an error should it occur is also low compared with other types of errors (e.g. page crashes).

**Fixing test failures after a change**. If a test is overly specific, then a change in implementation, even where it does not substantively change the functionality of the software, may cause the tests to fail. In this case the test suite has become a burden and a cost on the development team rather than facilitating change. 

This cost is magnified even more in the case of over-specific view tests, where the views may be changed by frontend developers who may not be so familiar with the full test suite or need help from a backend developer to fix test failures. 

> If removing something from a template doesn't break something, the test coverage is weak.

I disagree, and so does the creator of Test Driven Development, Kent Beck:

> "I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence"
[Kent Beck, Stack overflow 30/9/2008](http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565)

Automated tests should target coverage to the types of mistakes likely to be made in your team or by other collaborators. The aim is not to get '100%' coverage, but to reduce the *risk* of errors in the cheapest way possible. This is about probability and risk, there's no black-or-white approach applicable under all circumstances.