Страницы

четверг, 22 ноября 2012 г.

CardFlow. Приёмочный тест.

Любую разработку стоит начинать с приёмочного теста. Чем приёмочный тест отличается от модульных тестов? В первую очередь приёмочный тест – это тестирование всей функциональности системы с точки зрения конечного пользователя. Скажем, если вы нажали кнопку добавить в корзину – то необходимо проверить содержимое корзины на соответствие добавленному товару. Пользователь – это не обязательно человек. Если речь идёт про RESTful-сервис – то пользователь это другой сервис. Важная особенность – тестируют по принципу чёрного ящика, все действия с сервисом только через внешние интерфейсы или внешнее API. Хотя при этом надо использовать заглушки на внешние системы – лишняя недетерминированность ни к чему. Кроме того, заглушки могут эмулировать особые случаи поведения внешних систем (ошибки, разрывы связи и т.д).

Обычно приёмочные тесты пишутся на языке Gerkin. С этим же языком и работает SpecFlow, с помощью которого я и собираюсь писать тест. Для тех кто не знаком со SpecFlow, рекомендую посмотреть примеры. Кода немного, и можно быстро понять что к чему, даже не читая документацию.

Первый тест лучше писать для  минимальной реализации, постепенно докручивая в нём фишки. В моём случае это простейшее действие – создание новой Kanban-доски с указанными параметрами. У меня получилось так:

Как начать реализовывать систему – расскажу в следующий раз.

PS. Намучившись с форматированием кода решил окончательно переехать на gist’ы от github. Получается гораздо быстрее, и чище исходник блога.

воскресенье, 18 ноября 2012 г.

CardFlow. EventStore.

По жизненным обстоятельствам пришлось временно оставить профессию блоггера, но к счастью у меня оно снова есть. За это время утекло много воды, пришло много интересных идей (о которых вечно не хватает времени написать), я стал счастливым обладателем Windows 8 (честно счастливым, но об этом в другом раз). А еще пришло понимание, что свободного времени много не будет. Всё это приводит меня к неизбежности мысли уменьшить масштаб учебного проекта – оставить только создание и редактирование Kanban-досок.

В прошлый раз я остановился на поиске шины для приложения. Пришло время сделать еще один выбора – Event Store.  Но выбор был простым:

Признаюсь, от первого варианта я ждал многое, но ожидания мои не совсем оправдались. Вещь действительно хорошая быстрая, продуманная, со средствами мониторинга и другими плюшками, которые чрезвычайно полезны в реальных системах. Нет одной определяющей вещи – поддержки тестирования на уровне инфраструктуры.

Что это значит? Для тестов жизненно необходимы три вещи Arrange, Act, Assert. Все шага должны выполняться быстро. Очень быстро. В вопросе хранения данных это означает возможность запустить хранилище в том же процессе. Совсем идеально хранить данные в памяти. Такой режим есть например в RavenDB. Да даже Microsoft озаботилась тестированием, и сотворила IIS Express для тестирования. В случае Грега Янга мы имеем только отличный сервер, что для быстрых тестов совершенно не годиться.

Второй вариант сразу с главной страницы подкупил наличием такого режима. В остальном тоже неплохо, поддержка разных способов хранения данных, разных логгеров (включая встроенную возможность логгировать в консоль – плюсик для тестов). Конфигурация простая, понятно даже без документации.

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

В следующий раз расскажу про самое главное, с чего следует начинать разработку – приёмочный тест.