Naming of unit tests - Should we follow a guideline?

I had this very interesting discussion with some fellow developers and post here a quick Q&A

Question
>>If a unit test fails - do you fix it by looking at the name of the test, or do you fix it by looking at the unit test?

Answer
By looking at the name of the unit test, you know what is broken, as per definition of "Unit test". (A unit test should test only 1 small unit of work)
So you don't need to actually read and understand the test, which saves you HEAPS of time!!

If you have an exception with stack trace you probably start with that

 

Question
>>If you have to change the unit test code, do you then update the name, because it is now out of sync?

Answer
You should ask yourself why you change the unit test code

1. If the unit test code has a bug, than you *don't need* to change the name.
   Fix the test
2. If the production code is broken, you *don't need* to change the name.
   Fix the production code
3. If the requirements change, you *need* to change the name or delete the test, because the requirements changed
   Because your "tests" act as documentation, the name change is VERY welcome

 

I think this misunderstanding comes from mixing up: "Unit test" and all other tests, like "Integration test", "System test" and "End to End test"
There is a big difference between a "Unit test" and all other tests, see Definition of Unit test