Pull to refresh
  • by relevance
  • by date
  • by rating

Цель покрытия кода: 80 % и не меньше!

Lumber room
Translation
Однажды рано утром молодой программист обратился к великому мастеру: «Я готов написать несколько модульных тестов. К какому покрытию кода я должен стремиться?».
Читать дальше →
Total votes 15: ↑14 and ↓1 +13
Views 220
Comments 2

Юнит-тестирование в Qt

IT systems testing *Programming *Qt *
Tutorial

gollum подметил что в тексте картинки есть ошибка

Салют, хабр! Как дела?

Хотел немного подучится чему-то. Искал на хабре в хабе «Qt Software» хоть какой-то пост про юнит-тестирование в Qt. Не нашел. Тут я расскажу базовые вещи про юнит-тестирование на Qt (не ожидайте могучего шаманства). На самом деле, юнит-тестить в Qt довольно просто. Что бы узнать как это делать, приглашаю читать дальше.
Читать дальше →
Total votes 35: ↑31 and ↓4 +27
Views 67K
Comments 21

Проблемы тестирования: почему 100% покрытие кода это плохо

Positive Technologies corporate blog IT systems testing *Python *Web services testing *


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

Материал подготовлен на основе выступления разработчика Positive Technologies Ивана Цыганова на конференции Moscow Python Conf (слайды, видео).
Читать дальше →
Total votes 40: ↑34 and ↓6 +28
Views 28K
Comments 39

Code Coverage — хочу верить

Programming *Designing and refactoring *TDD *
Разработчик обязан знать свои инструменты! Знание инструментов увеличивает продуктивность, эффективность, производительность, потенцию разработчика! Не могу программировать без R#!

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

Правда, инструкция к инструменту обычно не содержит раздел «Противопоказания», не указываются ситуации когда НЕ стоит применять утилиту. Между тем, подобный раздел мог бы сэкономить тонны времени на неудачные эксперименты.

Сегодня я пошвыряю камни в огород Code Coverage (CC). Достаточно полезная метрика, под которой лежат несколько скудно документированных граблей.
CC в посте не описывается. Читайте на свои страх и риск.
Total votes 36: ↑35 and ↓1 +34
Views 29K
Comments 32

Антипаттерны тестирования ПО

IT systems testing *TDD *Debugging *Web services testing *Development Management *
Translation

Введение


Есть несколько статей об антипаттернах разработки ПО. Но большинство из них говорят о деталях на уровне кода и фокусируются на конкретной технологии или языке программирования.

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

Терминология


К сожалению, в тестировании пока не выработали общую терминологию. Если спросить сотню разработчиков, в чём разница между интеграционным, сквозным и компонентным тестом, то получите сто разных ответов. Для этой статьи ограничимся такой пирамидой тестов:


Если не видели пирамиду тестов, настоятельно рекомендую ознакомиться с ней. Вот некоторые хорошие статьи для начала:

Читать дальше →
Total votes 48: ↑48 and ↓0 +48
Views 69K
Comments 31

Оценка тестового покрытия Java проекта на примере Apache Ignite

Abnormal programming *Open source *IT systems testing *Java *
Sandbox

Я участвую в развитии open source проекта Apache Ignite, работая над проектом мне стало интересно оценить тестовое покрытие и вот что из этого получилось.


Читать дальше →
Total votes 14: ↑14 and ↓0 +14
Views 7.1K
Comments 0

По дороге к 100% покрытия кода тестами в Go на примере sql-dumper

IT systems testing *Programming *Designing and refactoring *Go *

image


В этом посте я расскажу о том, как я писал консольную программу на языке Go для выгрузки данных из БД в файлы, стремясь покрыть весь код тестами на 100%. Начну с описания, зачем мне нужна была это программа. Продолжу описанием первых трудностей, некоторые из которых вызваны особенностями языка Go. Дальше немного упомяну сборку на Travis CI, а затем расскажу о том, как я писал тесты, пытаясь покрыть код на 100%. Немного затрону тестирование работы с БД и файловой системой. А в заключении скажу о том, к чему приводит стремление максимально покрыть код тестами и о чём говорит этот показатель. Материал я сопровожу ссылками как на документацию, так и на примеры коммитов из своего проекта.

Читать дальше →
Total votes 25: ↑23 and ↓2 +21
Views 6.8K
Comments 7

Неприятные ошибки при написании юнит тестов

IT systems testing *JavaScript *Node.JS *Web services testing *
На днях я буду делать внутренний доклад, на котором расскажу нашим разработчикам про неприятные ошибки, которые могут возникнуть при написании юнит тестов. Самые неприятные с моей точки зрения ошибки — когда тесты проходят, но при этом делают это настолько некорректно, что лучше бы не проходили. И я решил поделиться примерами таких ошибок со всеми. Наверняка ещё что-нибудь подскажете из этой области. Примеры написаны для Node.JS и Mocha, но в целом эти ошибки справедливы и для любой другой экосистемы.

Чтобы было интереснее, часть из них оформлена в виде проблемного кода и спойлера, открыв который, вы увидите, в чём была проблема. Так что рекомендую сначала смотреть на код, находить в нём ошибку, а затем открывать спойлер. Решения проблем указано не будет — предлагаю самим подумать над ним. Просто потому, что я ленивый. Порядок списка не имеет глубокого смысла — просто это очерёдность, в которой я вспоминал про всякие реальные проблемы, которые доводили нас до кровавых слёз. Наверняка многие вещи покажется вам очевидными — но даже опытные разработчики могут случайно написать такой код.

Читать дальше →
Total votes 34: ↑32 and ↓2 +30
Views 9.7K
Comments 14

Снимаем покрытие кода с уже запущенного Node.JS приложения

JavaScript *Node.JS *Web services testing *

И снова я про тестирование и покрытие.



Наверное, вы уже поперхнулись кофе от вопроса "Зачем снимать покрытие с запущенного приложения" — но такая потребность периодически возникает.


Например:


  • Узнать покрытие интеграционных тестов без инстурментализации кода, завершения приложения и выгрузки репорта какими-то сторонними средствами;
  • Узнать без долгого ковыряния кода, по каким именно модулям приложения прошёл запрос;
  • Определить "мёртвый" код, который по факту не используется в приложении;
  • Узнать список транзитивных зависимостей, которые используются на определённые запросы.

Интересно? Поехали!

Читать дальше →
Total votes 11: ↑9 and ↓2 +7
Views 3.1K
Comments 0

PhpStorm 2020.1: поддержка composer.json, инструменты для PHPUnit, покрытие кода с PCOV и PHPDBG, Grazie и другое

JetBrains corporate blog Website development *PHP *


Привет, Хабр! Рады представить первый мажорный релиз PhpStorm в этом году!

Под катом подробный разбор всех заметных изменений и новых возможностей. Осторожно — много картинок.
Total votes 74: ↑74 and ↓0 +74
Views 16K
Comments 139

Улучшения покрытия PHP кода в 2020 году

Конференции Олега Бунина (Онтико) corporate blog PHP *
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 стал доступен новый способ оценивать покрытие.
Читать дальше →
Total votes 33: ↑32 and ↓1 +31
Views 6.3K
Comments 3

Как правильно готовить автоматизацию или Что покрывать тестами в первую очередь

Яндекс.Практикум corporate blog Python *Development of mobile applications *Mobile applications testing *
Привет, это Эрик Бурыгин, я техлид курса «Автоматизатор тестирования на Java» в Яндекс.Практикуме и лид в Яндексе. Каждый ручной тестировщик считает, что автоматизация — это круто и её непременно нужно втащить в проект. Что может быть лучше, чем полное покрытие автотестами продукта, когда тесты гоняются 24/7 и отлавливают баги? Вот прочитал я эти строки, и захотелось ещё раз всё заавтоматизировать!



Но, как это часто бывает, при внедрении автоматизации вы тратите много человеческих ресурсов, а профита долгое время не видно. Возникает вопрос о целесообразности этой инициативы. То, что на первых этапах автоматизация отнимает много сил — вполне нормально, но в перспективе она должна экономить время, а не наоборот. Попробуем понять, как этого добиться.
Читать дальше →
Total votes 7: ↑6 and ↓1 +5
Views 4.2K
Comments 2