Can I have more than one describe per test spec?

Question

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?

Answer 1

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.