Должны ли юнит-тесты проверять REST API?

Question

Некоторое время назад я тестировал свою бизнес-логику отдельно от уровня REST Api.
В интеграционных тестах я тестировал сам сервис на соответствие его API.

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

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

Мой вопрос заключается в том, должен ли я просто отказаться от тестирования бизнес-логики с помощью объектов, которые их реализуют, и от службы, чтобы объединить все случаи без дублирования усилий?

Примечания:

• Я не имею в виду отбрасывать все юнит-тесты. Достаточно сложные юниты, которые не касаются уровня API напрямую, должны по-прежнему тестироваться отдельно.
• Время выполнения теста здесь не проблема.

Обновление

Добавлен пример псевдокода для пояснения

class Book:
  id: int
  title: string


class BookRepository:
  add_book(book: Book) -> Book
  remove_book(id: int) -> bool
  all() -> List[Book]


class BookApi:
  repository = BookRepository()

  @route('/api/books')
  get() -> List[Book]

  @route('/api/books/id', method=POST)
  add(request_body) -> bool :
    book = parse_book_from_request(request_body)
    return repository.add(book)

  @route('/api/books/id', method=DELETE)
  delete() -> bool

Answer 1

Из вашего описания я вижу ситуацию следующим образом:

У вас есть два сценария модульного тестирования, а именно модульное тестирование бизнес-логики и модульное тестирование уровня REST.У вас также есть сценарий тестирования взаимодействия, а именно взаимодействие между уровнем REST и бизнес-логикой.И у вас есть сценарий тестирования подсистемы, а именно тест подсистемы, образованной уровнем REST и бизнес-логикой вместе.

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

Что может помочь вам здесь, так это спросить себя о каждом изэти сценарии тестирования, какие ошибки еще могут существовать, что другие тесты еще не устранены.Если вы думаете о тестовом примере, но тогда вы не можете думать ни о какой ошибке, которую может обнаружить тест, возможно, тестовый пример не нужен или его цель уже была решена другим способом.

Переход от дна кtop: у вас есть юнит-тесты для бизнес-логики.Итак, какие юнит-тесты могут иметь смысл для уровня REST?Вы упомянули десериализацию, но возможны также проверки достоверности и обработка некорректных запросов.Все это требует тщательного тестирования, в том числе отрицательных по соображениям безопасности.Подумайте об ошибках, которые вы могли бы найти на изолированном уровне REST - они, очевидно, не обнаружены модульными тестами изолированной бизнес-логики.

Теперь, входя в тесты взаимодействия (или интеграционные тесты):Целью этих тестов является только взаимодействие между соответствующими частями, а не то, делает ли какая-либо из сторон правильные действия после этого (что было проверено с помощью юнит-тестирования).Другими словами, тесты проверяют, вызываются ли правильные функции с аргументами в правильном порядке с правильными форматами - или, в более общем случае, если обе стороны интерфейса имеют одинаковое понимание.Граничные случаи также имеют смысл и здесь - например, посмотреть, может ли вызываемый объект справиться с крайними случаями, которые предоставляет вызывающий.Следует признать, что здесь существует риск избыточности, если интерфейс между компонентами велик по сравнению с размером компонентов.

Однако вы можете ограничить избыточность некоторыми способами: Предположим, что ваш уровень REST разработан для фильтрацииневерные book_id значения.Вы хотите проверить, принимается ли бизнес-логикой самый большой book_id, который должен пройти уровень REST.Если бизнес-логика сама проверяет book_id и, если она не принята, выдает исключение, ваш тест взаимодействия может сосредоточиться на том, было ли выброшено исключение или нет.Вам не нужно проверять, что была найдена правильная книга - это было проверено, когда бизнес-логика тестировалась модульно.

Затем подсистема тестирует: Опять подумайте, какие ошибки, возможно, не были обнаружены, которые могутможно найти только при взгляде на подсистему в целом.Например, выполняет ли подсистема все требования или какая-то функция была забыта?(В модульном тестировании не будут обнаружены забытые функции, возможно тестирование взаимодействия, но не во всех случаях.) Может ли быть несовпадение версий, которое может определить тест?И снова попробуйте сосредоточить тест на основных аспектах, чтобы избежать избыточности с помощью модульных тестов и тестов взаимодействия.

Извините, что я мог дать лишь несколько абстрактных советов с абстрактными примерами.