I started to writing tests a few time ago and faced a non-mature question: can I have more than one describe per unit test file?
If so, in what circumstances this will happen?
Because so far, I’m describing a/an module/object like this:
tests/User-spec.js
describe ('A user', function () {
it ('should add a "to do" into the list', function () {
var user = new User;
var list = new List({ name: 'Home' });
user.add('Buying some groceries.').to(list);
expect(list.items[0]).to.be('Buying some groceries.');
});
});
In other words, each file of my tests describes an object—there’s no space for another describe.
I know there are a few good/bad practices about tests, and technically I can add more than one describe per spec—I just do not know wether this is the “best” way to go or even good.
Can you describe to me some scenarios where more than one describe could be within the same spec file? Or even wether my describe is or isn’t wrong?
I’m going to assume you’re using the Jasmine testing framework since that’s the only one I know of with describe() and it().
Yes, it’s totally fine. The only thing that describe() does is designate a piece of text to be the “header” that describes a group of tests. The Jasmine intro page even says
The describe function is for grouping related specs
and Jasmine supports nested describes() too.
So the real question here is what is the most intuitive and readable way to group your tests. If it’s a small class with not very much to test, one header is probably fine.
Class A
Foo
Bar
Foo with non-ASCII characters
Bar with MAX_INT
If this is it, using more than one describe() is probably overkill.
After a few years of feature creep it may warrant a bit more.
Class A
Basic Calls
Foo
Bar
Baz
Shazam
Edge Cases/Regression Tests
Foo with non-ASCII characters
Bar with MAX_INT
Shazam after Foo(Bar(42*-6))
Baz before m_count is initialized
Compatibility Shims/Polyfills
Foo without generators
Bar without getPrototypeOf()
Do whatever makes the output more readable for your team.
1