2021-10-05 01:48:24
Продолжение темы тестирования своего говнокода
NOTE: На картинке API тесты находятся выше интеграционных. Но это условность. Все зависит от приложения и количества входных / выходных контроллеров. У вас может быть богатое REST API и ноль интеграций. Тогда у вас будет тонная API тестов и ни одного интеграционного. И наоборот, у вас может быть парочку web сервисов, и хуйва кукуева интеграций (например, используйте bpm движок).
Моя практика говорить, что в ряде случаев, API тесты возобладают над интеграционными. Особенно, когда мы разрабатываем ресурсные сервисы.
Есть такая вещь, называется пирамида тестирования. Она говорит нам о том, в каком объеме мы должны писать те или иные тесты. Теперь давайте посмотрим на пирамиду сверху вниз.
Мы видим, что наверху пирамиды располагаются UI тесты. К ним можно отнести мануальное тестирование. В идеале, у нас вообще не должно быть ручного тестирования. Но зачастую, оно есть. Как обычно решается эта проблема? Правильно - автоматизация. Например, тестами на selenium. Логично предположить, что если мы детализируем нашу пирамиду, то автоматизированные UI тесты будут ниже, чем мануальное тестирование.
Давайте опустимся еще ниже, где мы видим интеграционные тесты. Эти тесты задействуют большое количество функционала, а значит имеют очень много зависимостей, что приводит к их частым падениям. Интеграционные тесты призваны проверять интеграции между различными системами - сетевые доступы, контракты, пермишены и тд.
Если мы детализируем нашу пирамиду еще, то увидим ниже интеграционных тестов - контрактные тесты (API). Это тесты, которые в изоляции тестируют контракты вашего API. При этом, весь функционал должен быть замокан или застабирован.
Если мы пойдем еще ниже, то увидим компонентные тесты. Это тесты, которые покрывают ваш компонент (это абстрактная вещь, под компонентом как правило понимается функционал).
В самом низу, мы увидим родненькие unit тесты. Это тесты, которые проверяют наши методы в изоляции от любых зависимостей, подразумевая, что зависимости работают корректно.
Чем ниже мы спускаемся по пирамиде тестов, тем большее количество тестов подразумевает каждый слой. Поэтому, в первую очередь, мы должны все обложить маленькими, простыми и компактными unit тестами. Затем уже задуматься о модульных тестах, а уже затем, приступать к тестированию API (контрактов). Как правильно, тут наша задача заканчивается. Все, что выше контрактных тестов обычно пишут QA.
В следующем посте расскажу вам, как правильно писать unit тесты, потому что это отдельный вид искусства. И я очень серчаю, когда люди пишут убогие монструозные юниты, не понимая, какую проблему они ими решают и зачем вообще их пишут.
8.9K views22:48
J
