Мне нужно уточнить, какой из этих тестов является 100% модульным тестом, по стандартам модульного тестирования

Question

У меня есть две части кода, которые тестируют конечные точки API, я знаю, что модульные тесты не делают HTTP-запрос к серверу, так как я создаю службу API с фиктивными данными (просто используя массивы и другие структуры данных для хранения данных).Я хотел бы знать, какой из них действительно является модульным тестом (по истинному определению, что такое модульный тест)

Я прочитал много учебных пособий по TDD и BDD, и я понимаю, что первая версия кодаЭто приемочный тест, мой вопрос, во многих руководствах эта первая версия называется модульным тестом, но некоторые говорят, что это приемочный тест.Я немного запутался

// first version -- the one I believe to be acceptance test

it('should return a list of meetups that meets the search criteria', (done) => {
    agent
     .get('/api/v1/meetups/search')
     .query({ searchTerm: 'meetup 1' })
     .expect(200)
     .end((err, res) => {
         if (err) return done(err);
         res.body.status.should.equal(200);
         res.body.data.should.be.an('array');
         res.body.data.length.should.be.greaterThan(0);
         done();
     });
});

// second version -- using sinon to mock req and res object used in the route handler function

it('can search for meetups by topic', () => {
    const req = {
        query: {
            searchTerm: 'Sample Meetup'
        }
    };

    const res = {
          status() { },
          send() { }
    };

    res.status = sinon.stub(res, 'status').returns(res);
    res.send = sinon.stub(res, 'send').returns(res);

    myController.searchMeetups(req, res);
    res.status.firstCall.args[0].should.equal(200);
    res.send.firstCall.args[0].should.have.property('data');
    res.send.firstCall.args[0].data.length.should.be.greaterThan(0);
 });

Тест работает, для обеих версий я хочу получить разъяснения по поводу приемочного теста API, если он подходит для модульного теста для API

Answer 1

Добро пожаловать на SO!

То, что у вас есть, - это скорее приемочный тест.Это также, вероятно, будет считаться интеграционным тестом.

В этом тесте вы тестируете (дикая догадка - я не знаю, что именно делает ваш сервис, но, надеюсь, вы поймете идею):

• тот факт, что ваш сервер правильно работает
• , вероятно, один или несколько методов аутентификации, которые проверяют, что пользователь имеет все необходимые права для запроса этого URI
• , вероятно, многодругих промежуточных программных средств, правильной подготовки запроса, форматирования данных и т. д.
• может быть несколько взад-вперед с базой данных
• , возможно, немного инструментов для ведения журнала, отладки и т. д.
• основная функциональность вашего сервиса (возврат списка встреч в правильном формате)

Это много всего за один тест!И многие вещи могут пойти не так, если всего одна строка в сотнях строк кода, управляющих всем этим (некоторые вы написали, некоторые другие написали), содержит одну ошибку.И, наконец, единственное, что вас волнует, - это массив с несколькими элементами, который представляет собой функциональность, ожидаемую вашим пользователем, или accepts.Вот почему мы называем это UAT (или пользовательские приемочные тесты).

Вы также можете сказать, что это integration тест, поскольку вы тестируете отдельные части вашего приложения: сервер иdatabase.

Вы также можете услышать о E2E (сквозных) тестах: это, например, тестирование того, что веб-интерфейс также правильно отображает все собрания, полученные из только что протестированного бэкэнда.И многие другие типы тестов ...

Модульные тесты действительно тестируют самые маленькие тестируемые единицы кода, которые вы можете найти.В вашем сценарии существует множество функций во время выполнения вашего запроса.При заданном параметре X функция Y всегда будет возвращать Z?А как насчет функций A, B, C, D ...?

Иными словами: если ваш тест не пройден, вы знаете, какая часть вашего кода не работает?Что, если в вашем коде есть 2 проблемы, но так как запрос не выполняется при первой ошибке, как вы можете узнать?Кроме того: как вы можете быть уверены, что эта часть больше никогда не выйдет из строя?

Написание тестов немного утомительно, и есть много способов сделать это правильно.Иногда невозможно (или очень сложно) протестировать одну функцию без какой-либо другой зависимости (например, функцию, которая вызывает базу данных), и нельзя ожидать, что вы протестируете 100% очень очень большого проекта.Но вы должны стремиться к «достаточно большому» числу там.

И иногда проблема заключается в «склеивании» между проверенным модулем кодом.Проблемы с сетью могут возникать между прекрасно работающими функциями, условиями гонки или ... и в этом случае вам нужны интеграционные тесты.

Answer 2

Мнения ahoy:

Второй подход - это абсолютно юнит-тест.

Первый подход немного ближе к приемочному тесту, хотя я бы предпочел назвать его функциональный тест.Предположительно какая-либо база данных и т. Д. Все еще отключена.

Вопрос, который вы не задали, заключается в том, какой подход лучше для тестирования REST API?На мой взгляд, четкий ответ является первым подходом.Это дает вам серию тестов, максимально имитирующих опыт реального пользователя API, позволяет делать четкие и краткие заявления о значениях ответа и заголовка, возвращаемых для каждого теста, и т. Д.

Сохранитьмодульные тесты для ваших индивидуальных методов модели, сделать функциональные тесты для ваших методов контроллера.Это мои $ 0,02.