Доменные модели

Год назад мой друг Roberto Ciatti познакомил меня с концепцией, которую Роберт Мартин называет чистой архитектурой. Дядя Боб много говорит об этой концепции на конференциях и пишет о ней очень интересные статьи. «Чистая архитектура» представляет собой способ структурирования системы программного обеспечения, набор соглашений о различных слоях и ролях их участников, нечто большее, чем строгие правила.

Как он уже говорил в своей статье «Чистая архитектура» (перевод на хабре), идея самого подхода не нова, она строится на множестве концепций, которые продвигались многими разработчиками программного обеспечения в течение последних 3-х десяти лет.

Для начала я приведу небольшой тестовый проект из трёх классов, проанализирую его покрытие с помощью гема SimpleCov, а напоследок немного поразмышляю о том, как анализ покрытия может приносить пользу проекту, и какие есть недостатки у Coverage в Ruby.

Подопытный проект

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

# Мама очень заботится о своём сыне, и не разрешает ему гулять,
# если он не надел шарф. А ещё она заботится о его успеваемости, поэтому если
# сын не сделал домашнюю работу, гулять ему она тоже не разрешит.
class Mother
  def permit_walk?(child)
    child.scarf_put_on && child.homework_done
  end
end

Новые технологии — новые надежды

В этой серии статей мы строим программное обеспечение марсохода в соответствии со следующими спецификациями. Это позволит применить нам на практике следующие подходы:

• Monolithic Repositories — MonoRepo (Монолитные репозитории)
• Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
• Event Sourcing — ES (События как источник)
• Test Driven Development — TDD (Разработка через тестирование)

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

Марсоход должен будет сначала приземлиться в заданном положении. Положение состоит из координат (X и Y, являющихся целыми числами) и ориентации (строковое значение north, east, west или south).

Сегодня мы будем рефакторить LandRover:

В этой серии статей мы строим программное обеспечение марсохода в соответствии со следующими спецификациями. Это позволит применить нам на практике следующие подходы:

• Monolithic Repositories — MonoRepo (Монолитные репозитории)
• Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
• Event Sourcing — ES (События как источник)
• Test Driven Development — TDD (Разработка через тестирование)

Ранее мы создали пакет навигации, теперь можно приступать к разработке первого варианта использования:

Марсоход должен будет сначала приземлиться в заданном положении. Положение состоит из координат (X и Y, являющихся целыми числами) и ориентации (строковое значение north, east, west или south).

TDD не работает.

Правда? Странно. У меня всегда работал хорошо.

А вот новое исследование говорит об обратном.

Новое исследование?

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

Авторы считают его убедительным?

Авторы рекомендуют проводить новые исследования. Но они скорее всего просто скромничают. Результаты довольно убедительные.

Какие результаты?

• Monolithic Repositories — MonoRepo (Монолитные репозитории)
• Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
• Event Sourcing — ES (События как источник)
• Test Driven Development — TDD (Разработка через тестирование)

• Monolithic Repositories — MonoRepo (Монолитные репозитории)
• Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
• Event Sourcing — ES (События как источник)
• Test Driven Development — TDD (Разработка через тестирование)

В этой статье я хочу представить вам новую библиотеку для тестирования AVA. Относительно новую, ей уже больше 2-х лет, и она обзавелась солидным количеством плагинов и конечно же сообществом которое ее развивает. Мы посмотрим на функционал библиотеки. Настроим окружение и напишем пару тестов, чтобы посмотреть на библиотеку в действии.

Flask – это замечательный микро веб фреймворк, основанный на Python. Flaskr – это миниблог, который описан в официальном руководстве по Flask. Я продирался через это руководство больше раз, чем могу в этом признаться. Тем не менее, я хотел бы взять это руководство для следующего шага, добавив в него разработку через тестирование (test driven development) и немножко jQuery.

На одном из наших недавних проектов мы столкнулись с серьёзной проблемой. Веб-приложение, которое мы разрабатывали, должно было использовать внутренюю базу данных финансовой организации. Из соображений безопасности, доступ был очень сильно ограничен: любые изменения необходимо было делать при помощи хранимых процедур, а читать данные — только при помощи представлений. Таким образом, приложение должно было выполнять сложные манипуляции данными, не имея никакого представления об их структуре. Основной загвоздкой для нас было то, что наше приложение попадало в зависимость от больших и сложных процедур, для которых не существовало автоматизированных тестов.

Погуглив немного, мы обнаружили, что в штатном инструментарии Oracle SQL Developer [1] есть функционал для создания автоматизированных тестов. Мы тут же приступили к его изучению. И хотя тесты для самой сложной процедуры пришлось создавать уже после её написания, этот инструментарий всё же помог нам устранить несколько ошибок, а также существенно облегчил процесс расширения функционала и рефакторинга. Ниже я приведу пример использования TDD для построения хранимых процедур, а также поделюсь опытом в работе с инструментарием.

Привет, меня зовут Леонид, и я работаю в команде, использующей Ruby on Rails, в компании Align Technology.
На работе мы используем рельсы в связке с RSpec, и сегодня я поделюсь нашим опытом о том, как облегчить себе жизнь при помощи собственных тегов в тестах.

Часть 2

Продолжение статьи о написании UI тестов на Cucumber с помощью Selenide. В первой части был разобран простейший пример smoke-теста для riskmarket.ru. В этой части апгрейдим тест до полноценного проекта с отчетами, поговорим о скриншотах, кастомных Condition, проаннотируем элементы, введем PageObject.

Получившийся проект вполне можно использовать как фундамент для ваших UI тестов.

Проект на гитхабе

Видео исполнения теста на youtube