Рубрика «code coverage»

image

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

Читать полностью »

Newman и Continuous Integration на примере Atlassian Bamboo. Изобретение велосипеда - 1

Введение

В недавней статье наш боевой товарищ actopolus рассказал о том, как мы научились применять Postman для реализации функционального тестирования нашего API проекта. Научившись писать функциональные тесты, и написав их порядка полутора сотен, мы решили, что настало то самое время — время прикрутить эти тесты к нашим CI-сборочкам.

Вообще, изначально процесс интеграции Postman-тестов в сборки можно было разбить на 3 простых этапа:

  1. Формирование production-ready коллекции тестов для Postman
  2. Подготовка docker-образа среды для запуска тестов
  3. Написание тасков для того, чтобы собрать всё воедино и запускать на агентах

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

  1. Написание тасков для того, чтобы собрать всё воедино и запускать на агентах.

Читать полностью »

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

Объединяем Code Coverage от PHPUnit и phpspec - 1

Стремиться к стопроцентному покрытию кода нет никакого смысла, однако понимать в среднем какой процент кода покрыт вашими тестами — хорошая метрика при непрерывном интегрировании.

Мы можем настроить оповещения при падении процента покрытия, например, ниже 50, можем добавлять автоматические комментарии от ботов в пул реквестах, показывать тенденцию изменения Code Coverage на графиках с течением времени и т.д.

image

Но что делать, если вы используете несколько библиотек для тестирования? Как получить общее покрытие кода?
Читать полностью »

Захотелось мне объективных критериев качества кода и конечно я вспомнил про свои давние наработки (коллекцию нефункциональных тестов, см. тут и тут).
Ещё тогда была идея оформить их не в виде коллекции тестов, а в виде отдельной утилиты, но удалось сделать только теперь, встречаем perlqual (от perl quality).
Читать полностью »

Давайте общаться! Горячая весна от DevExpress - 1
Пока вся страна разыгрывает первоапрельские шутки, мы хотим поделиться с вами нашими нешуточными новостями.

Совсем скоро в Москве пройдут две крупные конференции для .NET разработчиков, и там вы сможете повстречаться с нами и вживую задать все интересующие вас вопросы!

Ниже вы узнаете, где и когда нас можно найти:

Читать полностью »

image Как известно из книги «Путеводитель для путешествующих автостопом по галактике», ответ на главный вопрос жизни, вселенной и всего такого — 42. Процент покрытия кода по линиям на одном из моих проектов — 81, дает ли эта цифра ответ на главный вопрос тестирования «cколько тестов достаточно для определения качества продукта»?

В течении своей работы в айти-сфере и тестировании я видела мало команд и проектов, где тестировщики реально используют code coverage в своей работе. Связано это на мой взгляд с двумя вещами:

1. Тем, что тестируем мы прежде всего требования;
2. Далеко не все понимают, как считать и использовать покрытие.

Интересующимся предлагаю свой взгляд на эти 2 пункта.
Читать полностью »

Процесс разработки и выкатка релизов в Badoo. Автоматическое тестирование. Девелоперское окружение
В июле мы вместе с ведущими IT-Kompot и релиз-инженерами Badoo Владиславом Черновым и Олегом Оямяэ записали выпуск подкаста «Процесс разработки и выкатка релизов в Badoo. Автоматическое тестирование. Девелоперское окружение».
Так как прошлый подкаст вызвал интерес у слушателей и читателей, то этот подкаст мы тоже превратили в статью.

О чем говорили:
Процесс разработки и выкатки релизов в компании Badoo. Используемые инструменты.

  • GIT Workflow. Каждая задача в отдельной ветке;
  • Использование JIRA, TeamCity и AIDA;
  • Формирование релиза и выкатка двух релизов в день. Проблемы и их решения (откат, патчи и т.д.).

Автоматическое тестирование. Рецепт быстрого прогона большого количества тестов.

  • Что мы используем;
  • Как гоняем тесты;
  • Code Coverage;
  • Пускалка. 18000 тестов за 3,5 минуты.

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

Читать полностью »

Предисловие

Этот топик не ставит своей целью рассказать о code coverage, и о том, нужно это средство или нет. Также, не будет подниматься вопрос о целесообразности тестов в iOS проектах (положим, что они все-таки кому-то нужы, а значит есть).

Мотивация

Очень удобно, когда средства для профилирования/анализа встроены в IDE. История С code coverage в xCode не совсем безоблачная: во времена xCode 3.x и GCC все было просто и нужные ссылки и флаги компилятора гуглились на раз. C приходом xCode 4.1 все стало немного сложнее ввиду использования LLVM-GCC, приходилось идти на некоторые ухищрения (вплоть до сборки LLVM своими руками). А в 4.3 библиотеку libprofile_rt переместили в другую директорию, что тоже вызвало немало проблем.Читать полностью »

JAVA / Mutation testing на примере Pitest Многие из вас, возможно, слышали про Mutation Testing в замечательном подкасте «Разбор полётов» или читали в википедии. Для тех, кто всё-таки с понятием пока не знаком, в двух словах объясню.

Мутационное тестирование — альтернативный подход к измерению качества ваших тестов. Вместо того, чтобы считать банальный code coverage, используется более разумный механизм. В байт-код ваших классов внедряются случайные изменения, иначе называемые мутациями. Если после такой мутации не упал ни один тест, который покрывает внесённыеЧитать полностью »