Question

If the expected result of the method being tested exists in the official documentation of the method, then indicating the expected result in the test names would be redundant. In fact, if the purpose is to document the method, then the documentation should be written in the method’s XML documentation which would provide Intellisense info and more.

Why must anything besides the method being tested really be included in a test name?

Answer 1

It’s a matter of convention and development practice. If you’re implementing using TDD, documenting the expected result in the test name keeps you focused on your goal. There is also no XML docs to specify the expected result on as you haven’t implemented the class yet. (You’re writing the test first.) The additional benefit here is that documenting the expected result in the test means that you can execute the specification (aka test) and verify that it is correct. You can’t execute XML docs. 🙂 (You do have to make sure that test name and test code match though. This is easier than making sure test code and XML docs in another file match.)

Beyond that, there are tools that will extract class/method names and generate specification documents for you in HTML. This allows you to easily generate reports that can be reviewed by all stakeholders. You would want to do this for high-level tests/specs, such as “When a 10 percent single-item discount code is applied during checkout, the most expensive item in the shopping cart is discounted by 10 percent.” This allows stakeholders to verify (because the specs are executing/passing) that the system implements certain business-relevant features.