My goal here is to normalize the exception messages.

Here are a couple of rules I have observed:

1. Surround interpolated values in single quotations. The exception to this is when the interpolated text is a comma delimited array representation -- in that case, surround the comma delimited array element values in braces.

2. Use consistent wording:

   Expected file contents to be equal to [{0}], but instead was given [{1}].
   Expected file contents to be '{0}', but instead was '{1}'.
   Expected error message for key '{0}' to contain '{1}', but instead found '{2}'.
   Expected controller '{0}' to have a model error for member '{1}', but none found.
   Expected HTTP status code to be '{0}', but instead received a '{1}'.
   Expected action result to be a {0}, but instead received a {1}.
   Expected result view to be '{0}', but instead was given '{1}'.
   Expected encoding to be equal to {0}, but instead was {1}.

All sentences begin with "Exception" and end with a full stop. They all adhere to the same general structure.

I think you did a much better job at being consistent than me. In particular, there are some minor discrepancies in the ShouldRenderFile code file (which I am responsible for):

Expected file contents to be equal to [{0}], but instead was given [{1}].
Expected file contents to be '{0}', but instead was '{1}'.

I will have a little think about this and then issue another commit by the end of the day most likely.

Whops.

I accidentally deleted my fork. When I clone master then am this patch and then make subsequent changes, they are not detected as an addition tot his pull request. I will have to close this one and create a new one.