No matter the test framework you use, and no matter if you are writing client side or server side unit tests, the main concern on adopt some "name convention" is to make sure that the test name clearly states to everyone what is the system and the behavior under testing.
Let's suppose we want to test this code:
var MyClass = (function () {
function MyClass() {
this.defaultMessage = "Hello person without a name";
}
MyClass.prototype.getHelloMessage = function (firstName, lastName) {
if (!firstName && !lastName) {
return this.defaultMessage;
}
var message = "Hello";
if (lastName) {
message += " " + lastName;
}
if (firstName) {
if (lastName) {
message += ",";
}
message += " " + firstName;
}
return message;
};
return MyClass;
})();
The above code just format a simple message with the given input parameters, if any, and return a default message if no parameters specified.
The module name for me would be the class name and a separator to make the list of test names more readable:
QUnit.module("MyClass tests - ");
One could simple name the test:
test("getHelloMessage test", function () {}
and assert all expectations in one text.
I prefer a more verbose approach, that would be clear to understand the purpose of each test:
test("getHelloMessage without input parameters should return default message", function () {});
test("getHelloMessage with only lastName should not display a comma", function () {});
test("getHelloMessage with only firstName should not display a comma", function () {});
This way each test has a clear purpose, they will be kept as small as needed, and when one test fail it is easy to understand what part of your code has been affected by the latest changes.
The good standard is the one that all members of your team agree that will help everyone to find and solve bugs, and also to help them write better unit tests.