MVC Unit Testing LocomotiveJS

Question

Я использую LocomotiveJS для создания приложения MVC. Я думал о типе тестов, которые я должен писать, и смущен.

Вот несколько компонентов в приложении - Модели, Представления, Контроллеры, Маршрутизатор и ORM.

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

1. Напишите тесты, чтобы гарантировать, что API, предоставляемый ORM, действует так, как я ожидаю.
2. Единичный тест моей модели, обрезающий ORM. Я предоставляю ему заглушку, поэтому мне не нужно полагаться на фактические операции с базой данных в своем модульном тесте.
3. Контроллер получает доступ к представлениям и моделям. Задача Контролера состоит в том, чтобы получить/изменить модель и ответить клиенту (render/redirect).
   • Ответ контроллера можно протестировать, предоставив им тестовые входы и проверив, сформирован ли правильный ответ (завершите render/redirect и убедитесь, что правильные звонки сделаны).
   • Управление моделью контроллером можно протестировать, выбирая модель и обеспечив правильные вызовы. Это кажется неправильным, так как я тестирую реализацию ...
4. Виды - это просто шаблоны; контроллер связывает шаблоны со значениями. Я мог бы создать модель поддельного представления и связать ее с представлением и посмотреть, генерируется ли правильный выход.
5. Маршруты просто берут запрос и сопоставляют его с правильным контроллером и действием. Я могу гарантировать, что правильные маршруты поддерживаются приложением, пропуская части маршрутизатора и убедившись, что запрос на маршрутизатор сопоставляется с ожидаемым контроллером/действием.

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

Это похоже на перебор.

Это имеет смысл?

Сделайте 1 и 2, как указано выше.

3. Интеграция протестирует остальные (контроллер/Вид/Маршрутизатор). Здесь я думаю, что мне нужно просто запустить свое приложение в среде test и использовать supertest, чтобы гарантировать, что запросы генерируют правильные ответы - посещая URL-адрес, я получаю правильный контент, правильные переадресации и т. Д.

Я думаю, что имеет смысл единичный тест модели, поскольку он представляет собой взаимодействие с другой системой (сохранение данных). Мы хотим убедиться, что мост функционирует должным образом. Router/Controller/View взаимодействуют в нашей собственной системе и очень специфически. Так что это нормально для интеграции теста. Что ты думаешь?

Answer 1

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

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