Интеграционные тесты в приложении Angular

Question

Я немного запутался в этом тесте:

  describe('#getUsers', () => {
    it('should return an Observable<User[]>', () => {
      const dummyUsers: User[] = [
        new User(0, 'John'),
        new User(1, 'Doe')
      ];

      service.getUsers().subscribe(users => {
        expect(users.length).toBe(2);
        expect(users).toEqual(dummyUsers);
      });

      const req = httpMock.expectOne(`${service.API_URL}/users`);
      expect(req.request.method).toBe('GET');
      req.flush(dummyUsers);
    });
  });

Я видел подобные примеры много раз, во время изучения тестов в приложениях Angular.

Если я вижу хорошо, мы объявляем массив Users, а затем мы возвращаем тот же массив в ответ на запрос.

Наконец, мы проверяем, совпадает ли созданный массив с полученным. Я не могу понять цель, это выглядит очень странно для меня.

Какой смысл сравнивать один и тот же массив с одним и тем же массивом?

Разве я не должен сделать реальный GET для API, а затем проверить, есть ли элементы в ответ?

Answer 1

Вы не проверяете данные, вы проверяете метод. Вы предоставляете некоторые данные и позволяете методу получать эти данные. Если метод работает правильно, вы должны получить те же данные, что и предоставленные.

Но я думаю, что ваша проблема больше в понимании юнит-тестов. Интеграционная часть теста идет после этого, где проверяются тип запроса и количество вызовов.

Я предполагаю, что трудно определить, где вы делаете разрез для интеграционного теста. Вы можете тестировать с реальным API, но вы также увеличиваете зависимости теста, и это усложняет их поддержку.

Я бы сказал, что проверка, если API вообще возвращает значения, легче тестировать в модульном тесте.