
Unit-тестированиеЧитать полностью »
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-тесты на них.
В этой статье я хочу на примере pg_skeleton подробней остановиться на том, как писать тесты для хранимых функций PostgreSQL при помощи pgTAP.
Читать полностью »
Приветствую читателей!
Хочу поделиться своими достижениями в налаживании контроля покрытия кода при модульном тестировании приложений под Windows Phone. Примечательно, что при решении этой задачки пришлось столкнуться с некоторыми аспектами «правильного» проектирования приложений. Поэтому этот пост можно рассматривать как небольшое учебное пособие.
Дано:
Начинается разработка небольшого приложения под Windows Phone. Приложение типовое — забирает какие-то данные со своего сервера и в каком-то виде их показывает пользователю.
Требуется:
Спроектировать архитектуру приложения так, чтобы при непрерывной интеграции максимум кода приложения, отвечающего за логику работы, был закрыт тестами с возможностью контролировать это покрытие.
Читать полностью »
Хочу поделиться опытом в настройке системы непрерывной интеграции для проекта Windows Phone 7 в Team City. Надеюсь, сэкономлю тем, кто пойдёт той же тропой, потраченные мной самим время и нервы.
Дано:
Необходимо:
Качественный код невозможен без тестов. А качественные тесты — без моков. В создании моков нам давно помогают различные полезные библиотечки, наподобие EasyMock или Mockito. В своей практике я использую Mockito, как самое гибкое, красивое и функциональное средство. Но, к сожалению, Mockito тоже не стал серебрянной пулей. Ограничением всегда являлись final классы, private поля и методы, static методы и многое другое. И приходилось выбирать: или красивый дизайн, или качественное покрытие тестами. Меня, как приверженца красивой архитектуры и качественных тестов, такой расклад не устраивал. И вот совсем недавно я наткнулся на замечательную библиотечку — PowerMock, которая удовлетворила практически все мои запросы. За исключением одного, но об этом позже.