Рубрика «Unit-тестирование»

«Серьезные» разработчики встраиваемых систем (читай: стмщики) время от времени любят шпынять голозадых «ардуинщиков», у которых среда разработки, помимо всего прочего, не поддерживает даже аппаратные отладчики с точками останова и просмотром значений переменных под курсором мышки или в специальной табличке в реальном времени. Что ж, обвинение вполне справедливо, окошко Монитора последовательного порта (Serial Monitor) плюс Serial.println — не самый лучший инструмент отладки. Однако грамотный ардуинщик сможет с легкостью парировать атаку и поставить зарвавшегося стмщика на место в том случае, если он (ардуинщик) использует модульные тесты.

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

Предисловие

В ходе разработки ios-приложения, перед разработчиком может встать задача unit-тестирования кода. Именно с такой задачей столкнулся я.

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

Хотя и существуют уже библиотеки для юнит-тестирования кода на С++, например, Google Test или Bandit, но они написаны не мной здесь оно, на мой взгляд, как-то переусложнено, по сравнению с тем же JS. Там просто делаешь, например, npm i mocha assert --save-dev и можно приступать к написанию тестов, а здесь же нужно это сделать ручками, а в случае с gtest еще и собрать с помощью cmake ее. Bandit подключается просто, но не умеет в сериализацию результатов в какой-то формат данных, gtest это умеет, но его нужно собирать отдельно. А я не хочу выбирать "либо то, либо это". Мне было нужно сделать удобный и простой инструмент под мои задачи. Я хотел получить простую библиотеку без зависимостей, header-only, на несколько файлов, которую можно легко и быстро подключить к своему проекту, удобно внести в нее изменения (если это будет необходимо). Но, самое основное, мне хотелось получать удобные, машиночитаемые отчеты, причем не только в stdout (или xml, как в gtest), но и в любой другой формат, который я захочу. Далее под катом.

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

Перевод статьи «Building robust web apps with React: Part 3, testing with Jasmine», Matt Hinchliffe

От переводчика: это перевод третьей части цикла статей «Building robust web apps with React»
Переводы:

Во второй части я покрыл процесс оптимизации моего браузерного приложения Tube Tracker, но каждое вносимое мной изменение до сих пор требует обновление браузера, чтобы проверить, что все работает. Приложение серьезно потребует набора тестов, чтобы ускорить процесс разработки и избежать регрессии кода. Как оказалось, это проще сказать, чем сделать, когда начинаешь работать с новой технологией, как React.
Читать полностью »

Недавно я выложил статью со «скелетом» схемы данных, который можно использовать для создания своих схем PostgreSQL.
Помимо собственно скриптов разворачивания схемы, создания объектов, там были примеры хранимых функций и Unit-тесты на них.

Тестирование хранимых функций с помощью pgTAP

В этой статье я хочу на примере pg_skeleton подробней остановиться на том, как писать тесты для хранимых функций PostgreSQL при помощи pgTAP.
Читать полностью »

Контроль покрытия кода при unit тестировании в Windows Phone
Приветствую читателей!
Хочу поделиться своими достижениями в налаживании контроля покрытия кода при модульном тестировании приложений под Windows Phone. Примечательно, что при решении этой задачки пришлось столкнуться с некоторыми аспектами «правильного» проектирования приложений. Поэтому этот пост можно рассматривать как небольшое учебное пособие.

Постановка задачи

Дано:
Начинается разработка небольшого приложения под Windows Phone. Приложение типовое — забирает какие-то данные со своего сервера и в каком-то виде их показывает пользователю.
Требуется:
Спроектировать архитектуру приложения так, чтобы при непрерывной интеграции максимум кода приложения, отвечающего за логику работы, был закрыт тестами с возможностью контролировать это покрытие.
Читать полностью »

Хочу поделиться опытом в настройке системы непрерывной интеграции для проекта Windows Phone 7 в Team City. Надеюсь, сэкономлю тем, кто пойдёт той же тропой, потраченные мной самим время и нервы.

Дано:

  1. Довольно-таки массивное приложение Windows Phone 7 c unit-тестами, реализованными средствами Silverlight Toolkit.
  2. Настроенная сборка приложения в TeamCity без запуска unit-тестов. Агент для сборки — «физическая» (в смысле, не виртуальная) машина.

Необходимо:

  1. Настроить ещё одного build-агента TeamCity на виртуальной машине под VMWare.
  2. Запускать unit-тесты при сборках и сбора результатов их выполнения в статистику TeamCity.

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

image
Качественный код невозможен без тестов. А качественные тесты — без моков. В создании моков нам давно помогают различные полезные библиотечки, наподобие EasyMock или Mockito. В своей практике я использую Mockito, как самое гибкое, красивое и функциональное средство. Но, к сожалению, Mockito тоже не стал серебрянной пулей. Ограничением всегда являлись final классы, private поля и методы, static методы и многое другое. И приходилось выбирать: или красивый дизайн, или качественное покрытие тестами. Меня, как приверженца красивой архитектуры и качественных тестов, такой расклад не устраивал. И вот совсем недавно я наткнулся на замечательную библиотечку — PowerMock, которая удовлетворила практически все мои запросы. За исключением одного, но об этом позже.

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