Об удобочитаемом именовании тестов в JS и поведенческом паттерне

[TimurNes]

describe('discoveryService => initDiscoveries',()=> {});

тоже плохой пример. Зачем в описании теста название тестируемого сервиса и метода?
Название сервиса можно вынести и в родительский describe, а в этом написать примерно такое:

describe('when initializing discoveries',()=> {
    beforeEach(
        // Setup success request mock
    )

    it('should clear existent discoveries', () => {
        discoveryService.initDiscoveries();
        expect(...).to...;
    });

    it('should load new discoveries', () => {
        discoveryService.initDiscoveries();
        expect(...).to...;
    }); 
});

следующий тест, на неуспешную загрузку:

describe('when initializing discoveries failed',()=> {
    beforeEach(
        // Setup failed request mock
    )

    it('should show error message', () => {
        discoveryService.initDiscoveries();
        expect(toastr.error)
            .toHaveBeenCalledWith('Failed to initialize discoveries');
    });
});

Гораздо же понятнее, когда предназначение теста и его поведение описывается «людским» языком, а не просто «сервис — метод»

[HomoLuden]

Согласен с Вами, однако мне кажется в Ваших примерах стоит все-таки добавить родительский describe. А то можно не вчитываясь прийти к неправильным выводам. А еще текстовочку чуть благозвучнее по-английски подправить.
Как-то так…

describe('discoveryService', () => {
describe('when discoveries initialization failed',()=> {
    beforeEach(
        // Setup failed request mock
    )

    it('should show error message', () => {
        discoveryService.initDiscoveries();
        expect(toastr.error)
            .toHaveBeenCalledWith('Failed to initialize discoveries');
    });
});

Данный тест в случае ошибки в консоль выведет:
/>
discoveryService
when discoveries initialization failed
should show error message

Читается естественным образом.