Rambler.iOS — периодические встречи iOS-разработчиков, проводимые компанией Rambler&Co. В мае мы собираемся уже в третий раз — и будем рады гостям!

Примечание автора: это перевод статьи Боба Мартина.
На написание этой статьи меня вдохновила статья Марка Симана «The IsNullOrWhiteSpace trap» (@ploeh). Статья Марка кратко и хорошо изложена. Пожалуйста, прочитайте сначала её, прежде чем продолжать читать данную.
Ловушка, о которой рассказывает Марк, это частный случай более общей ловушки, которую я называю воровством золота. Я могу продемонстрировать эту ловушку, возвращаясь обратно к статье Марка.

Заметьте, что первый тест, который написал Марк выглядел следующим образом:

[InlineData("Seven Lions Polarized"  , "LIONS POLARIZED SEVEN"  )]
[InlineData("seven lions polarized"  , "LIONS POLARIZED SEVEN"  )]
[InlineData("Polarized seven lions"  , "LIONS POLARIZED SEVEN"  )]
[InlineData("Au5 Crystal Mathematics", "AU5 CRYSTAL MATHEMATICS")]
[InlineData("crystal mathematics au5", "AU5 CRYSTAL MATHEMATICS")]

Он уже попал в ловушку. Почему? Потому что он уже украл золото.

Недавно была выпущена первая бета версия тестового фреймворка NUnit v3. Кроме всего прочего, эта версия реализует параллельное выполнение тестов (практически «из коробки»). Я решил проверить как это работает на одном реальном проекте и обнаружил, что новая версия nunit-а не поддерживает часть используемых вещей предыдущих версий. В частности предлагается вместо аттрибута ExpectedException использовать Assert.Thorws или Assert.That.
Независимо от релиза этой беты, в одном из проектов начал использовать модель Assert.That вместо всех остальных методов и атрибутов nunit-а.

Под катом небольшой опыт перевода аттрибута ExpectedException в модель Assert.That.

Недавно столкнулся с необходимостью написать кастомный матчер в jasmine. Первым же делом начал гуглить и нашел пример, где все четко и понятно объяснено. Собственно код представлен ниже:

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

В продолжение предыдущей статьи о тестировании интерфейсов в Тинькофф Банке расскажу, как мы пишем unit-тесты на javascript.

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

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

Может они просто не умеют их «готовить»?

Часть 1.
Часть 2.
Часть 3. DUnit + FireMonkey
Часть 3.1. По мотивам GUIRunner
Часть 4. Serialization

Здравствуйте, дорогие хабровчане.

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

Сейчас наш проект выглядит так:

Часть 1.
Часть 2.
Часть 3. DUnit + FireMonkey.
Часть 3.1. По мотивам GUIRunner.

Ещё в начале увлечения программированием мне нравилось работать с файлами. Работа, правда, в основном заключалась в чтении входных данных и записей результатов. Дальше была работа с БД, файлами я пользовался все реже. Максимум IniFile иногда. Поэтому задача сериализации была довольно интересной для меня.

Сегодня я расскажу о том, как мы добавили сериализацию в нашу программу, какие возникли трудности и как мы их преодолели. Так как материал уже не новый, то он скорее для новичков. Хотя, кое-какие приемы смогут почерпнуть покритиковать все.

Прочитав статью «Тестирование встроенных систем» и комментарии к ней я был несколько поражен тем фактом, что многие хабровчане знакомы с книгой «Test Driven Development for Embedded C (Pragmatic Programmers)» и framework-ом Unity, но не используют весь арсенал средств, которые предлагают ребята из throwtheswitch.org.

Хочу кратко поделится опытом использования этих самых средств.

Часть 1.
Часть 2.
Часть 3.

Сегодня дописал пост о том, как мы решили написать свой GUIRunner для FireMonkey. В комментарии к посту в одной из соцсетей Алексей Тимохин обратил мое внимание на другой известный фреймворк для тестирования — DUnitX.
Я пытался найти альтернативу, использовать консольный вариант, но Александр был неумолим. Когда же зайдя в репозиторий я увидел готовый GUIRunner под FireMonkey, совсем поник.

Однако.

Часть 1.
Часть 2.

Здравствуйте.

В этой статье я хочу познакомить читателей с процессом переноса VCL кода в FireMonkey. В стандартной поставке Delphi, начиная по-моему с версии 2009, проект DUnit идёт из коробки.

Однако писался он в далекие времена VCL. И хотя и позволяет тестировать код написанный для FireMonkey (Благодаря консольному выводу), но у него нет «няшного» GUIRunner'a, к которому многие из нас привыкли, ведь в нём очень быстро и легко можно «убрать» те тесты которые мы не хотим запускать «именно сейчас».

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

Я уже давно слышал про способ тестирования, который используется в QuickCheck, но всё никак не хватало финального толчка, чтобы им заняться вплотную. Этим толчком стала эта презентация от Джона Хьюза, автора этой замечательной библиотеки.

В чём заключается QuickCheck-подход

Описать суть подхода можно довольно просто: мы не создаём тесты-примеры, а вместо этого задаём правила, которые определяют поведение системы на произвольных входных данных. Библиотека сама генерирует большое количество случайных входных данных и проверяет, соответствует ли поведение кода установленным правилам. Если это не так, то она показывает нам, на каком примере происходит падение теста.

Звучит многообещающе? Вполне.

В данной публикации я расскажу о том, как подружить Linux (ubuntu server 14.04) с Selenium Server v.2.43.1, о подводных камнях и зачем мне в облаке понадобился сервер для автоматических тестов.



Не так давно на Хабре была опубликована статья «Автотесты – барское дело». Я считаю, что в команде, где более 2-х разработчиков работают над одним проектом — это просто необоходимая вещь. Когда я работал один, обходился без тестов. Проект писался с нуля, код я знал как свои 5 пальцев. Компания росла очень быстро — в месте с ней и количество задач. Появились новые разработчики, тут то и начались проблемы. Пишем один функционал — отваливается другой. Не подумайте, такое случалось редко, но такие ошибки стоили дорого и нужно было с этим бороться. В это время я принял решение ввести автотесты в процесс разработки, о чем ни капли не жалею.

Сейчас я решил еще больше оптимизировать процесс тестирования. Идея в том, чтобы автоматически запускать тесты при поднятии функционала на дев, продакшин. Преимущества такого подхода очевидны и о них уже писали не раз. Как минимум — это моя уверенность в том, что тесты отработали и при заливке на продакшин ничего не сломается.

Я являюсь участником проекта по разработке ОСРВ Embox для встроенных систем. Чаще всего ОС для встроенных систем поддерживает множество аппаратных платформ, и мы не исключение. Также в проекте имеется множество сервисов и библиотек: ssh, telnet, Qt и т.д. Все эти сервисы и библиотеки хотелось бы иметь в рабочем состоянии на различных платформах.

Я хорошо помню то время, когда именно мне приходилось поддерживать в рабочем состоянии Qt. Это был ужас! Вот я пришел днем на работу, что-то опять сломано. Начинаю разбираться. Оказывается, что кто-то пофиксил багу в сетевом стеке и теперь Qt не может создать сокет. Короче говоря, Qt ломалось практически ежедневно и по самым неожиданным причинам.

Естественно, напрашивалось решение внедрить в проект некоторое автоматизированное тестирование различных сервисов. В чем же проблема сделать сервер, который будет все это тестировать?

Основная проблема заключается в специфике встроенных систем. А именно, в отличие от систем общего назначения, тестам приходится выполняться в среде со специфической аппаратной поддержкой. Например, у них мало памяти, и поставить средство интеграционного тестирования внутрь такой железки не представляется возможным. То есть нужно тестировать «снаружи». Итак, давайте ближе к делу.

Вы, мои дорогие, когда-либо представляли себе процесс тестирования, идущий задом наперед? Если да, то вы уже знакомы с TDD!

Немножко истории

Сейчас мы с вами будем говорить об одной из методик экстремального программирования и тестирования. Но сначала — Тойота! Да-да, именно та самая Тойота, компания, которая делает весьма неплохие, как по мне, автомобили. Какое они имеют отношение к тестированию, тем более экстремальному? Да самое непосредственное! И нет, я не имею ввиду тесты софта на скорости в 180 км/час. Это было бы глупо. Весело, но глупо.

TDD (Test-Driven Development), или, если по-нашему, — разработка, основанная на тестировании — это достаточно интересная методика, но, как по мне, TDD звучит круче, а посему я буду именно так называть её здесь. Мы же круты, верно?

Предлагаю к ознакомлению вольный перевод статьи Джейсона Хатчерса «TDD⁽¹⁾ is ‘canard. Tell it to the Duck» или дословно: «TDD — Утка. Скажи это утке». ⁽²⁾

Автор критикует «ортодоксальный» TDD подход к разработке и предлагает альтернативный.

И, да, в заголовке статьи нет опечатки ⁽³⁾.

В первой части был написан лексер, а во второй части — парсер. Далее будет рассмотрена разработка вычислителя и фасада для всего интерпретатора, а также рефакторинг кода для устранения дублирования.

Вычислитель

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

• Если на вход подан операнд, он помещается на вершину стека.
• Если на вход подан знак операции, то соответствующая операция выполняется над требуемым количеством значений, извлечённых из стека, взятых в порядке добавления. Результат выполненной операции кладётся на вершину стека.
• После полной обработки входного набора символов результат вычисления выражения лежит на вершине стека.

В данной статье я не буду реализовывать контекст выполнения и вычисление нескольких выражений. Поэтому начальный список тестов будет коротким:

• Если на входе пустой список, возвращаем 0.
• Если на входе список с одним числом, возвращаем это число.
• Если на входе [1 2 +], возвращаем 3.

Создадим новый тестовый класс и добавим первый тест.

TEST_CLASS(EvaluatorTests) {
public:
    TEST_METHOD(Should_return_zero_when_evaluate_empty_list) {
        double result = Evaluator::Evaluate({});
        Assert::AreEqual(0.0, result);
    }
};

В первой части был написан лексер. Далее будет рассмотрена разработка парсера.

Парсер

Парсер будет реализован по алгоритму сортировочной станции, так как он достаточно прост и не нуждается в рекурсии. Сам алгоритм таков:

В начале даются пустой выходной поток и пустой стек. Начнём читать токены из входного потока по очереди.

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

После достижения конца входного потока, вытолкнуть все оставшиеся в стеке операторы в выходной поток. Если в нём найдено что-либо кроме операторов, то генерируем ошибку.

Прикинем, какие тесты могут понадобиться для начала.

• При получении пустого списка, возвращается пустой список.
• При получении списка с одним числом, возвращается список с этим числом.
• При получении [1 + 2], возвращается [1 2 +].
• При получении [1 + 2 + 3], возвращается [1 2 + 3 +], так как оператор + является лево ассоциативным.
• При получении [1 * 2 + 3], возвращается [1 2 * 3 +].
• При получении [1 + 2 * 3], возвращается [1 2 3 * +], так как оператор * имеет больший приоритет.

Со скобками и ошибками разберёмся позднее. Итак, напишем первый тест из списка.

TEST_CLASS(ParserTests) {
public:
    TEST_METHOD(Should_return_empty_list_when_put_empty_list) {
        Tokens tokens = Parser::Parse({});
        Assert::IsTrue(tokens.empty());
    }
};