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

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

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

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

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

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

Одна из интересных вещей относительно Perl 6 заключается в удивительной легкости, с которой происходит создание новых модулей/библиотек и добавление их в Perl 6 Ecosystem (аналог CPAN для Perl 6). Давайте разберемся, как же создаются новые модули для Perl 6.

На протяжении последних нескольких месяцев я практиковал TDD. Теперь я понимаю — эта техника (не путать технику и методологию!) работает. Ее легко использовать и она эффективно решает вполне конкретные проблемы. Эта заметка адресована программистам и, в меньшей степени, руководителям проектов.