I mainly write unit tests right now so I do not know if this is applicable to integration tests / functional tests but here goes.
There are two main principles that I try to keep in mind. The first is to test the component as a whole instead of the methods, the other is to test (and document) the intent not the action.
This would for instance mean that instead of have a few tests like “TestCreateUserIndexOutOfBoundsException” there would be “TestUserRegistrationErrorRecovery” and in that test there will be plenty of actions that produces errors and asserts that checks the correct responses. There might be another which is “TestInputValidation”. This allows for a few things. If I have a component that is “UserRegistration” there will be a test which is the “UserRegistrationTest”, thus I do not need to add UserRegistration in the individual test because that is already documented in the name of the test file. The other thing is does is that when I change something I need to think if I have changed the intent of the component and update the tests. If I have not I do not need to add, change or remove tests.
From what I remember from Functional tests is that test execution is a thing and that you might have finer control over what tests that actually gets executed which would argue for finer control over asserts and not grouping them. But in that case I still would suggest a naming scheme in terms of “Will Always Run”, “Will Only Run if the this function have changed”, “Only for troubleshooting purposes if the previous tests failed in order to get a better understanding on what exactly went wrong”. Again the intent of the test here is documented with regards to execution.
If I were to continue to translate this to functional testing I would probably try to come up with a scheme like this in the case of a web application.
Group test according to User Missions (let’s use twitter as an example). Register User, Tweet (the verb not the noun), Retweet, Read Flow, Update Profile etc.
Each area will typically contain a few standard parts like “Basic”, “Input validation”, “ErrorHandling”, “Localisation” and maybe a few specific parts for that area alone.
So to get to the naming it would be Tweet.Basic, Tweet.Localisation. And then I would probably update test suites so I have one which is “All Areas Basic Tests” which I will always run for instance.
Lot’s of thoughts in one post. Good topic!