Best practice guide for documenting unit tests?
A set of a unit tests for a project 3+ years old, now fail. It seems the tests themselves have become out of date, and I've wasted time trying to find non existent bugs.
To prevent this happening again, I will update the unit tests to correct values, and want to document why the input data is and expected results are correct.
Any advice and recommendations on best practices to do this, to make it easier for the next guy on this project would be very helpful right now.
Carefully name tests reflecting requirement in the form of input data & expected result.
I have been in similar situation but for integration UI tests, where it really helped us when we started carefully naming the tests with single specific requirement although sometimes names were very long.
We made sure that test name should unambiguously reflect an single direct requirement(or sub requirement) which should be understandable to all team members.
When we open an old test and if we really need to dig inside the test method to understand it, then its clear indication we need to rename it correctly to reflect input & output w.r.t. to an requirement.