Записки программиста

Ранее мы научились писать модульные тесты на языке Go и измерять степень покрытия кода тестами. Также недавно мы познакомились с GitHub Actions и узнали, как с его помощью автоматически собирать и тестировать проект. Казалось бы, проверять code coverage при помощи GitHub Actions должно быть проще простого. Используем материалы двух предыдущих статей, и готово! Но если бы все было так банально, вы бы сейчас не читали эти строки.

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

Большинство современных приложений представляют собой распределенные системы. Допустим, ваша компания делает «просто» приложение для мобильных устройств. Но помимо самого приложения, с которым работает пользователь, наверняка есть и какой-то сервер-сайд. Он состоит из балансировщиков нагрузки (например, Nginx), некоторого количества микросервисов, а те в свою очередь ходят в некие СУБД (PostgreSQL), кэши (Redis, Memcached) и service discovery (Consul). СУБД скорее всего крутится не на одном сервере, а имеет энное количество реплик — для распределения нагрузки, аналитики и снятия бэкапов. По моему скромному опыту, многие люди не сильно задумываются над проблемами, которые могут возникать в подобных системах. Давайте же выясним, что это за проблемы.

На первый взгляд, модульные тесты в Go пишутся очень просто. Создаем файл с именем пакет_test.go, в нем объявляем функции с именами TestЧтоТестируем, говорим go test, ну и считай готово. Однако на деле все оказывается чуточку сложнее. Например, оказывается, что из коробки в языке нет ни ассертов, ни моков. А когда ты начинаешь генерировать моки, они внезапно начинают участвовать в подсчете покрытия кода тестами. В общем, давайте разберемся, как все устроено на самом деле.

Как и любой уважающий себя язык программирования, C++ имеет фреймворки для написания модульных тестов, и даже не один, а очень много. В рамках этой заметки мы познакомимся с основами использования фреймворка Google Test. Это довольно легковесный, однако не в ущерб удобству и функциональности фреймворк, используемый в Chromium, LLVM, Protobuf, OpenCV, и других проектах. Кроме того, из IDE с ним умеет интегрироваться как минимум CLion.

Определение степени покрытия кода тестами — это очень-очень важно как минимум по двум причинам. Во-первых, с его помощью вы проверяете, что тесты выполняют каждую из написанных вами строк кода хотя бы один раз. Если это не так, скорее всего, у вас довольно фиговые тесты. Во-вторых, вы можете найти «мертвый» код, который на самом деле никогда не выполняется, и выкинуть его. Сегодня мы выясним, как посмотреть code coverage в программах, написанных на языке C или C++.

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

Property-based тесты — довольно простая, но очень полезная штука. Идея в следующем. Вы описываете инвариант в стиле «для любых данных, таких, что … выполняется условие …». При этом, в отличие от обычных тестов, вы не задаете явно все тестовые примеры, а только описываете свойства, которым они должны удовлетворять. Сами же примеры генерируются автоматически фреймворком для property-based тестирования. Если после определенного числа прогонов со случайными данными, удовлетворяющих описанию, условие действительно выполняется, тест считается пройденным. Иначе фреймворк пытается как можно сильнее сжать (shrink) пример, на котором тест завалился, после чего выводит его и завершает тест с ошибкой.

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

Снова и снова я сталкиваюсь с тем, что QA, тестировщики, или как их там у вас называют, не умеют нормально писать багрепорты. Что хуже, они и не хотят учиться делать это правильно. Что намного хуже, часто это касается не только QA и багрепортов, а команды и тикетов вообще в Jira, Trello, или чем вы там пользуетесь.