Однажды рано утром молодой программист обратился к великому мастеру: «Я готов написать несколько модульных тестов. К какому покрытию кода я должен стремиться?».
Юнит-тестирование в Qt
6 min
Tutorial
gollum подметил что в тексте картинки есть ошибка
Салют, хабр!
Хотел немного подучится чему-то. Искал на хабре в хабе «Qt Software» хоть какой-то пост про юнит-тестирование в Qt. Не нашел. Тут я расскажу базовые вещи про юнит-тестирование на Qt (не ожидайте могучего шаманства). На самом деле, юнит-тестить в Qt довольно просто. Что бы узнать как это делать, приглашаю читать дальше.
Проблемы тестирования: почему 100% покрытие кода это плохо
7 min
Недавно в нашем блоге мы рассказывали об использовании предметно-ориентированных языков для решения конкретных задач разработки с помощью Python. Сегодня речь пойдет о тестировании — в частности, о том, почему стопроцентное покрытие тестами кода это на самом деле плохо.
Материал подготовлен на основе выступления разработчика Positive Technologies Ивана Цыганова на конференции Moscow Python Conf (слайды, видео).
Code Coverage — хочу верить
4 min
Разработчик обязан знать свои инструменты! Знание инструментов увеличивает продуктивность, эффективность, производительность, потенцию разработчика! Не могу программировать без R#!
Подобного рода фразы можно услышать от абсолютно разных людей: фанатиков разработки, продавцов различных утилит, пользователей удобных тулз. Слышит их и мой менеджер, когда мне хочется поэкспериментировать с чем-то новеньким.
Правда, инструкция к инструменту обычно не содержит раздел «Противопоказания», не указываются ситуации когда НЕ стоит применять утилиту. Между тем, подобный раздел мог бы сэкономить тонны времени на неудачные эксперименты.
Сегодня я пошвыряю камни в огород Code Coverage (CC). Достаточно полезная метрика, под которой лежат несколько скудно документированных граблей.
Подобного рода фразы можно услышать от абсолютно разных людей: фанатиков разработки, продавцов различных утилит, пользователей удобных тулз. Слышит их и мой менеджер, когда мне хочется поэкспериментировать с чем-то новеньким.
Правда, инструкция к инструменту обычно не содержит раздел «Противопоказания», не указываются ситуации когда НЕ стоит применять утилиту. Между тем, подобный раздел мог бы сэкономить тонны времени на неудачные эксперименты.
Сегодня я пошвыряю камни в огород Code Coverage (CC). Достаточно полезная метрика, под которой лежат несколько скудно документированных граблей.
Антипаттерны тестирования ПО
31 min
Translation
Введение
Есть несколько статей об антипаттернах разработки ПО. Но большинство из них говорят о деталях на уровне кода и фокусируются на конкретной технологии или языке программирования.
В этой статье я хочу сделать шаг назад и перечислить высокоуровневые антипаттерны тестирования, общие для всех. Надеюсь, вы узнаете некоторые из них независимо от языка программирования.
Терминология
К сожалению, в тестировании пока не выработали общую терминологию. Если спросить сотню разработчиков, в чём разница между интеграционным, сквозным и компонентным тестом, то получите сто разных ответов. Для этой статьи ограничимся такой пирамидой тестов:
Если не видели пирамиду тестов, настоятельно рекомендую ознакомиться с ней. Вот некоторые хорошие статьи для начала:
- «Забытый слой пирамиды автоматических тестов» (Майк Кон, 2009)
- «Пирамида тестов» (Мартин Фаулер, 2012)
- «Блог отдела тестирования Google» (Google, 2015)
- «Пирамида тестов на практике» (Хэм Фокке, 2018)
Оценка тестового покрытия Java проекта на примере Apache Ignite
5 min
Я участвую в развитии open source проекта Apache Ignite, работая над проектом мне стало интересно оценить тестовое покрытие и вот что из этого получилось.
По дороге к 100% покрытия кода тестами в Go на примере sql-dumper
7 min
В этом посте я расскажу о том, как я писал консольную программу на языке Go для выгрузки данных из БД в файлы, стремясь покрыть весь код тестами на 100%. Начну с описания, зачем мне нужна была это программа. Продолжу описанием первых трудностей, некоторые из которых вызваны особенностями языка Go. Дальше немного упомяну сборку на Travis CI, а затем расскажу о том, как я писал тесты, пытаясь покрыть код на 100%. Немного затрону тестирование работы с БД и файловой системой. А в заключении скажу о том, к чему приводит стремление максимально покрыть код тестами и о чём говорит этот показатель. Материал я сопровожу ссылками как на документацию, так и на примеры коммитов из своего проекта.
Неприятные ошибки при написании юнит тестов
9 min
На днях я буду делать внутренний доклад, на котором расскажу нашим разработчикам про неприятные ошибки, которые могут возникнуть при написании юнит тестов. Самые неприятные с моей точки зрения ошибки — когда тесты проходят, но при этом делают это настолько некорректно, что лучше бы не проходили. И я решил поделиться примерами таких ошибок со всеми. Наверняка ещё что-нибудь подскажете из этой области. Примеры написаны для Node.JS и Mocha, но в целом эти ошибки справедливы и для любой другой экосистемы.
Чтобы было интереснее, часть из них оформлена в виде проблемного кода и спойлера, открыв который, вы увидите, в чём была проблема. Так что рекомендую сначала смотреть на код, находить в нём ошибку, а затем открывать спойлер. Решения проблем указано не будет — предлагаю самим подумать над ним. Просто потому, что я ленивый. Порядок списка не имеет глубокого смысла — просто это очерёдность, в которой я вспоминал про всякие реальные проблемы, которые доводили нас до кровавых слёз. Наверняка многие вещи покажется вам очевидными — но даже опытные разработчики могут случайно написать такой код.
Чтобы было интереснее, часть из них оформлена в виде проблемного кода и спойлера, открыв который, вы увидите, в чём была проблема. Так что рекомендую сначала смотреть на код, находить в нём ошибку, а затем открывать спойлер. Решения проблем указано не будет — предлагаю самим подумать над ним. Просто потому, что я ленивый. Порядок списка не имеет глубокого смысла — просто это очерёдность, в которой я вспоминал про всякие реальные проблемы, которые доводили нас до кровавых слёз. Наверняка многие вещи покажется вам очевидными — но даже опытные разработчики могут случайно написать такой код.
Снимаем покрытие кода с уже запущенного Node.JS приложения
5 min
И снова я про тестирование и покрытие.
Наверное, вы уже поперхнулись кофе от вопроса "Зачем снимать покрытие с запущенного приложения" — но такая потребность периодически возникает.
Например:
- Узнать покрытие интеграционных тестов без инстурментализации кода, завершения приложения и выгрузки репорта какими-то сторонними средствами;
- Узнать без долгого ковыряния кода, по каким именно модулям приложения прошёл запрос;
- Определить "мёртвый" код, который по факту не используется в приложении;
- Узнать список транзитивных зависимостей, которые используются на определённые запросы.
Интересно? Поехали!
PhpStorm 2020.1: поддержка composer.json, инструменты для PHPUnit, покрытие кода с PCOV и PHPDBG, Grazie и другое
9 min
Привет, Хабр! Рады представить первый мажорный релиз PhpStorm в этом году!
Под катом подробный разбор всех заметных изменений и новых возможностей. Осторожно — много картинок.
Улучшения покрытия PHP кода в 2020 году
10 min
Translation
А вы знали что метрики покрытия вашего кода врут?
В 2003 году Дерик Ретанс (Derick Rethans) выпустил Xdebug 1.2. Впервые в экосистеме PHP появилась возможность собирать данные о покрытии кода. В 2004 году Себастьян Бергманн выпустил PHPUnit 2, где впервые это использовал. У разработчиков появилась возможность оценивать эффективность своих наборов тестов, используя отчеты о покрытии.
С тех пор функциональность перенесли в универсальный независимый компонент php-code-coverage. В качестве альтернативных драйверов появились PHPDBG и PCOV. Но фундаментально основной процесс для разработчиков за последние 16 лет не поменялся.
В августе 2020 года с релизом php-code-coverage 9.0 и связанных с ним релизов PHPUnit 9.3 и behat-code-coverage 5.0 стал доступен новый способ оценивать покрытие.
В 2003 году Дерик Ретанс (Derick Rethans) выпустил Xdebug 1.2. Впервые в экосистеме PHP появилась возможность собирать данные о покрытии кода. В 2004 году Себастьян Бергманн выпустил PHPUnit 2, где впервые это использовал. У разработчиков появилась возможность оценивать эффективность своих наборов тестов, используя отчеты о покрытии.
С тех пор функциональность перенесли в универсальный независимый компонент php-code-coverage. В качестве альтернативных драйверов появились PHPDBG и PCOV. Но фундаментально основной процесс для разработчиков за последние 16 лет не поменялся.
В августе 2020 года с релизом php-code-coverage 9.0 и связанных с ним релизов PHPUnit 9.3 и behat-code-coverage 5.0 стал доступен новый способ оценивать покрытие.
Как правильно готовить автоматизацию или Что покрывать тестами в первую очередь
9 min
Привет, это Эрик Бурыгин, я техлид курса «Автоматизатор тестирования на Java» в Яндекс.Практикуме и лид в Яндексе. Каждый ручной тестировщик считает, что автоматизация — это круто и её непременно нужно втащить в проект. Что может быть лучше, чем полное покрытие автотестами продукта, когда тесты гоняются 24/7 и отлавливают баги? Вот прочитал я эти строки, и захотелось ещё раз всё заавтоматизировать!
Но, как это часто бывает, при внедрении автоматизации вы тратите много человеческих ресурсов, а профита долгое время не видно. Возникает вопрос о целесообразности этой инициативы. То, что на первых этапах автоматизация отнимает много сил — вполне нормально, но в перспективе она должна экономить время, а не наоборот. Попробуем понять, как этого добиться.
Но, как это часто бывает, при внедрении автоматизации вы тратите много человеческих ресурсов, а профита долгое время не видно. Возникает вопрос о целесообразности этой инициативы. То, что на первых этапах автоматизация отнимает много сил — вполне нормально, но в перспективе она должна экономить время, а не наоборот. Попробуем понять, как этого добиться.
Оценка (не)покрытия кода по результатам динамического анализа
7 min
Создание любого ПО сопровождается ошибками. Программисты ошибаются в выборе типов, ошибаются в реализации алгоритмов. Аналитики ошибаются в формулировке требований к ПО, и из этих ошибок рождаются ошибки в функционировании готового продукта. Любой (ну ладно, почти любой) производитель программных продуктов хочет обезопасить себя от ошибок в выпускаемом ПО. Для того чтобы избежать типовых ошибок придумали различные стандарты (типа MISRA C) и утилиты для анализа написанного кода (например, Lint). Но корректно написанный код - это половина проблемы, вторая половина - это насколько верно и полно код реализует требования к программе, и нет ли в программе того чего там быть не должно. Ответ на эти вопросы в свою очередь дает тестирование и проверка покрытия кода (например, gcov).
Иногда, в случае если программное обеспечение является частью системы, имеющей повышенные требования к безопасности, (например, в авионике), требуется доказать что весь код на уровне исполняемого образа программы корректен и не содержит «лишнего». Вот тут-то и приходится задействовать весь выше озвученный арсенал средств и засесть за анализ того что получилось из исходного кода.
Инструментирование ассемблерного кода для сборки данных о динамическом покрытии
14 min
В этой статье я опишу методику инструментирования на основе промежуточного ассемблера которую использовал для создания иллюстраций к своей предыдущей статье. Данный метод в частности используется таким инструментом как LDRA, с которым мне недавно пришлось столкнуться в рамках одного проекта...