Большинство современных приложений представляют собой распределенные системы. Допустим, ваша компания делает «просто» приложение для мобильных устройств. Но помимо самого приложения, с которым работает пользователь, наверняка есть и какой-то сервер-сайд. Он состоит из балансировщиков нагрузки (например, 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, или чем вы там пользуетесь.

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

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