Рубрика «unit-testing» - 3

Про ScalaCheck

Часть 1. Введение.

ScalaCheck — это комбинáторная библиотека, значительно облегчающая написание модульных тестов на Scala. В ней используется подход property-based тестирования, впервые реализованный в библиотеке QuickCheck для языка Haskell. Существует множество реализаций QuickCheck: есть реализации для Java, C, а так же других языков и платформ. Использование данного подхода позволяет значительно сократить время на разработку тестов.

Эта серия статей во многом похожа на мою предыдущую, посвященную Parboiled, поэтому и структура повествования будет похожей. Я расскажу вам, для чего всё это нужно, затем мы научимся смотреть на мир сквозь призму свойств и генераторов, а потом перейдём к более сложным вещам. Заинтересовало? Прошу под кат.

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

PODAM Java объекты для Unit-тестирования - 1

Добрый день!
При unit-тестировании часто сталкиваешься с необходимостью заполнять сложные объекты, чтобы возвращать их со стороны заглушек или наоборот — давать их на вход методам и тестам. Некоторые разработчики игнорируют get-set конвенции Java, а даже если геттеры и сеттеры есть, то заполнение объекта достаточно сложной структуры порой требует больше кода, чем сам тест. Это анти-паттерн Excessive Setup, и хочется научиться с ним бороться. В этой статье я расскажу, как с помощью библиотеки PODAM заполнять объекты быстро и красиво, продолжая идеи разумной рандомизации как входных данных для тестов, так и данных, возвращаемых заглушками — покажу на примерах, пороюсь в исходниках.
Итак, чтобы долго не думать, но и не заниматься миром животных, сгенерим страну. Читать полностью »

Тестирование в CСравнительно недавно была статья «Полуавтоматическая регистрация юнит-тестов на чистом С», в которой автор продемонстрировал решение задачи с использованием счётчиков из Boost. Следуя этому же принципу, была предпринята (успешная) попытка повторить данный опыт уже без использования Boost из соображения нелогичности наличия в проекте на C зависимости от Boost, да ещё и в таком небольшом объёме. При этом в тестах присутствовали вспомогательные директивы препроцессора в большом количестве. И всё бы так и осталось, но практически на завершающей стадии был найден альтернативный способ регистрации, который позволяет полностью избавится от дополнительных действий. Это C89-решение для регистрации тестов и чуть более требовательное к системе сборке решение для регистрации наборов тестов.Читать полностью »

CxxMock — принцип действия - 1
Иногда бывает интересно изучить архитектуру какого либо изделия, и посмотреть как оно устроено. Вот бывало разберешь часы, а обратно собрать не можешь… Но в отличии от часов программные продукты при доступе к исходникам можно разобрать, и собрать. А найденные решения применять уже в своей практике.

Когда у меня возникла необходимость в создании CxxMock, о котором я писал в статье CxxMock — Mock-объекты в C++, я разобрал принцип действия похожего GoogleMock. Или еще раньше разобрал основную идею c10k сервера mathopd, что последующих проектах позволило мне лучше маневрировать в проектировании архитектуры.

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

Если вы верите в Agile и разработка через тестирование для вас является нормой, а не какой-то непонятной практикой, но наверное столкнулись с такой нехорошей проблемой как организацией тестирования объектов которые используют другие объекты через интерфейсы на C++.

Если для .NET есть замечательная библиотека Rhino.Mocks, которой достаточно «скормить» интерфейс и вы получаете возможность программирования поведения методов интерфейса прямо в модульном тесте. То для С++ все сильно сложнее, так как нет замечательного рефлекшена который позволяет строить код во время исполнения. И приходится писать объекты-заглушки вручную. И в случае изменения интерфейса приходится не только обновлять все классы в приложении но обновлять весь набор «одноразовых» классов заглушек реализующих интерфейс которые применяются в тестах.
Читать полностью »

Перевод статьи «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.
Читать полностью »

Только ленивый ещё не писал о необходимости писать тесты. Но давайте признаемся честно — писать тесты зачастую скучно. Особенно для legacy-кода. Сотни повторяющихся, однообразных строк. Скука. Что с этим можно сделать?

image
Картинка для привлечения внимания. Красивый питон, да?
Читать полностью »

Добрый день хабр.
Вчера вышла версия 1.1.0 test.it — фреймворка для тестирования js кода.
Он, наконец, обзавёлся функционалом, отсутствие которого делало его неполноценным:

  • Асинхронные тесты/группы
  • Запуск отдельных тестов/групп

А так же прочими мелочами.

картинка для привлечения внимания
Кто не любит много слов — Сайт на котором можно увидеть код в действии, GitHub, WikiЧитать полностью »

Картинка для привлечения внимания:
test.it habrahabr
Я — начинающий веб-разработчик. И не так давно мне захотелось научиться работать так, как это делают настоящие программисты.
Под этим я понимал 3 основных элемента:

  1. Использование системы контроля версий.
  2. Грамотное комментирование кода.
  3. TDD или хотя бы простое юнит-тестирование кода.

Для первого пришлось освоить азы git, и создать свой первый репозиторий на github. Для второго выбрал JsDoc, из-за которого пришлось перебраться с notepad++ на sublime text (только там был соответствующий плагин).
А вот с третьим, неожиданно для меня, возникли серьёзные трудности.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js