Comments 4
Вроде статья называется "как начать тестировать бэкенд?", но по сути это лишь краткое описание инструментов (спасибо, что краткое), отличие БТ от ФТ, советы (некоторые странные, особенно если учитывать, что материал для тех кто уже долго в этом варится) и никакой конкретики
Поиск по тексту не нашёл таких ключевых фраз как: модульное тестирование, unit, юнит, qa, интеграционное тестирование
Может быть это не про то "как" тестировать, а "чем"? А "как" это делается мы узнаем позже?
Соглашусь с предыдущим оратором - как-то не увидел тут системного подхода.
Со своей стороны могу заметить, что (ну если так можно выразится) фундамент для тестов закладывают архитектор и разработчик. Тем, что должны предусмотреть обязательной систему логирования. Причем, очень хорошо если уровень детализации должен быть настраиваемый.
У нас (ну тоже своего рода "backend", не в том смысле как его принято понимать, но в том, что все это "где-то там на серверах крутится в фоне и что делает не видно снаружи") сложилась практика трех уровней:
В лог выводятся только ошибки. Это базовый, не отключаемый уровень. Любая ошибка должна быть перехвачена и запротоколирована как можно более тщательно для дальнейшего расследования. При этом лог мониторится службой сопровождения в реальном времени.
Ошибки + предупреждения. Это следующий уровень. Под предупреждением понимается ситуация, которая не является штатной, но, в отличии от ошибки, позволяет продолжить работу модуля.
Ошибки + предупреждения + трейсы. Это отладочный уровень. Практически никогда не включается на промсреде, только на тестовых юнитах. Вывод трейсовых сообщений закладывается разработчиком - они расставляются во всех ключевых точках и по ним можно отследит по каким веткам кода с какими параметрами шла обработка. В 90% случаев это позволяет даже без отладчика понять где что не так пошло.
Естественно, все логи имеют определенную глубину хранения (вряд ли кого будет интересовать что там было неделю назад - все расследования проводятся по горячим следам).
Кроме того, в ряде случаев еще ведутся т.н. "рабочие таблицы" в которых фиксируется что обрабатывалось и с каким результатом (буквально все). Например, нужно сделать выборку клиентов по определенным параметрам и обработать их по заданному алгоритму в несколько потоков. По рабочей таблице потом можно судить о том, какие клиенты попали в выборку, какими потоком обработались (можно оценить сбалансированность распределения нагрузки по потокам) и с каким результатом.
Добавлю.
В наших случаях обычно ситуация такова - модуль запускается с некоторыми входными параметрами и на выходе должен или вернуть какой-то ответ, или произвести некоторые изменения в данных (БД).
Есть автотесты для которых прописываются сценарии (многократный вызов модуля с разными входными параметрами и заранее известным результатом) и после каждого сценария полученный результат сравнивается с ожидаемым (возвращенные данные или изменения в БД).
Для тех случаев, где результат не совпал с ожидаемым проводится ручное тестирование - отдельный запуск нужных тест-кейсов с последующим анализом трейс-логов.
Но тут не всегда все однозначно. Иногда бывают ситуации, когда отдельный тест-кейс сам по себе проходит, но дает ошибку в сочетании с предыдущим кейсом. Например, если запустить последовательность
Case(1) - passed
Case(2) - failed
но при этом отдельный запуск
Case(2) - passed
Т.е. ошибка в Case(2) проявляется только при запуске его после Case(1)
Такие ситуации более сложны т.к. требуют выявления закономерностей (обычно проявляются для систем, где требуется высокая эффективность и много различных кешей - где-то что-то не сбросилось, не перезагрузилось и т.п.).
Как начать тестировать backend и не сойти с ума