Добрый день!
Представим что есть простое NodeJS приложение с MongoDB базой, все работает у нас в контейнерах и например в локальном кластере Minikube (классический туториал при поиске "nodejs mongo kubernetes").
Также мы помним, что у нас есть пирамида тестов:
UI
Integration
Unit
Вопросы:
1. [Unit] нужно ли запускать Unit тесты в кластере? (хотя по-другому неясно как)
Как тогда запускать не все, а скажем один нужный? (писать скрипт, который будет пересобирать образ с нужным тестом, обновлять deployment и перезапускать pod в кластере?)
2. [Unit] как смотреть что тесты выполнились? (подключаться к логам контейнера и по ним уже понимать? хотя наверно тоже можно написать скрипт для всего этого)
3. [Integration] Т.к. в этих тестах проверяется совместная работа NodeJS + Mongo контейнеров, как тестам дожидаться старта Mongo контейнера?
До UI тестов я еще не дорос.
Э а чем ваши [Unit] отличаются от [Integration], если вы собрались для них запускать ПО?
Если для запуска unit тестов вам нужно запустить само ПО, 99,9% вы идете не в ту сторону)
В целом unit тесты должны заблокировать попадание кода в "основную" ветку системы контроля версий, если данный код не прошел их.
Maxim Firsov Maxim Firsov Автор вопроса
Фиг с unit, может я правда с ними ошибаюсь, но что делать с Integration? Господа, как вы их запускаете? Какой вообще workflow разработчика в контексте TDD+k8t? Например, вы пишете кусок авторизации в Api сервисе, надо проверить что юзер регистрируется/входит/удаляется и т.д. Как пишется тесты конкретно для этих случаев и запускаются?
Какой вообще workflow разработчика в контексте TDD+k8t?
TDD — методика написания кода: тесты, потом код (ну грубо говоря)
До деплоя (там где контейнеры и вот это все) прилетает код и тесты вместе (что ч ТДД, что без) и то есть разницы нет никакой!
Да никто вам не ответит, нельзя ответить не зная проекта, может у вас там наверчено, что его только запустив можно узнать рабочий ли )
1. Все, что можно проверить не запуская проверять так.
2. Все, что можно подменить при запуске или вовсе не запускать (Модули не относящиеся к функционалу, реальные БД, ...), подменить / выкинуть из тестового запуска.
3. Как понять какие тесты запускать по репе / проекту в репе / директории в проекте
4. В идеале тесты должны быть быстрые, такие, что вопрос тратить время на реализацию фильтрации тестов или запустить все перевешивал во вторую сторону
Maxim Firsov, судя по вашим лычкам -- у вас там приложения не из моего стека, потому сильно там вам не подскажу.
НО на примере бекенд-приложения обычно запуск делается как обычно — поднимаются контейнеры, у контейнера с бекендом/nginx есть входная точка (или в виде урла или в виде ip или прост ов контейнер суемся с RUN) и запускаем тесты.
В случае функциональных тестов — вообще дерагем тестовый фреймворк и он сам внутри все вызовет
Максим Федоров на самом деле я лезу в back-end, и пока стек такой какой я написал: NodeJS/Mongo контейнеры через Ingress, и пока там обычное API (работа с пользователям и файлами). Наверняка, это какой-то распространенный случай (обычно 90% сервисов используют регистрацию вход в том или ином виде) и я не могу найти в инете, внятный tutorial с запуском тестов.
Да readness/liveness уже прочитал, спасибо.
Вопрос такой, а обычный цикл разработки, он как выглядит?
1. поправил кусок кода
2. пересобрал образы
3. деплой в minikube
4. как-то проверить что все ок.
Верно?
Можете сказать что с дебагом, конкретно NodeJS приложения?
Я немного погуглил, есть https://github.com/okteto/okteto , https://github.com/telepresenceio/telepresence которые позволяют разными способами пропускать пункты 2-3.
Maxim Firsov, я вижу процесс разработки немного со стороны - я DevOps. Так что про дебаг не скажу.
А согласно методологии DevOps (+ TDD и т.п.) все должно быть автоматически - сделали commit/push, активизировалась система CI (Continuous Integration), которая запускает static code analyse, security scan, unit tests, integration tests и т.п.
Я больше занимаюсь вот этой автоматизацией.
Простой
Простой
Средний
