Какой смысл использовать Fit/FitNesse вместо тестов интеграции в стиле xUnit? На мой взгляд, это действительно странный и очень неясный синтаксис.Почему Fit/FitNesse?
Действительно ли это только для того, чтобы владельцы продуктов пишут тесты? Они не будут! Это слишком сложно для них. Так зачем же Fit/FitNesse?
Обновление Так что это полностью подходит только для тестов бизнес-правил?
Все дело в том, чтобы работать с не программистами, часто даже совершенно нетехническими людьми, такими как потенциальные пользователи бизнес-приложения, на том, что приложение должно делать, а затем помещать в тесты. Несмотря на то, что выполнение тестов для них слишком сложно, они должны иметь возможность обсуждать таблицы выборочных данных, заполненных, например, Слово. И главное, в отличие от традиционной спецификации, эти документы живут с вашим приложением, потому что автоматические тесты заставляют вас обновлять их.
См. Introduction To Fit и Fit Workflow от James Shore и следуйте ссылкам на остальную документацию, если хотите.
Update: Зависит от того, что вы имеете в виду бизнес-правилами? ;-) Некоторые люди понимают это очень узко (например, в машинах бизнес-правил и т. Д.), Другие - очень широко.
Как я вижу, Fit - это инструмент, который позволяет записывать бизнес-примеры (как в домене) с богатыми реалистичными примерами в документе, которые могут понять конечные пользователи или эксперты домена (в некоторых доменах) проверить и обсудить. В то же время эти примеры находятся в машиночитаемой форме, поэтому их можно использовать для автоматизации автоматизированного тестирования. Вы сами не пишете документ самостоятельно и не требуете их для этого. Вместо этого это продукт общения и обсуждения, который отражает растущее понимание того, что приложение собирается делать с обеих сторон. Примеры становятся все более богатыми по мере продвижения, и устранены более угловые случаи.
Какое приложение будет делать, а не как, важно. Это форма функциональной спецификации. По сути, он довольно обширен и не организован модулями, а скорее сценариями использования.
Тестирование, которое приходит из примеров, будет проверять внешнее поведение приложения в аспектах, важных с точки зрения бизнеса. Да, вы можете назвать это бизнес-правилами. Но давайте посмотрим на пример кредитоспособности Диего Янсича, просто с небольшим завихрением. Что, если часть документа подстановки - это 1) перечисление атрибутов и их баллы, а затем 2) предоставление данных клиента и проверка результатов, тогда которые являются фактическими бизнес-правилами: таблица оценки (атрибуты и их оценки) или логика приложения, вычисляющая оценку для каждого клиента (на основе таблицы подсчета очков)? И какие протестированы?
Тесты Fit/FitNesse более подходят для приемочных испытаний. Другие тесты (когда вы не заботитесь о сотрудничестве с клиентами, пользователями, экспертами в области и т. Д., Просто хотите автоматизировать тестирование), вероятно, будет проще писать и поддерживать более традиционными способами. xUnit хорошо подходит для тестирования модулей и тестов api. Каждая веб-инфраструктура должна иметь некоторый инструмент для тестирования веб-приложений и сервисов, интегрированный в его цикл модификации-сборки-тестирования-развертывания, например. У django есть свой маленький тестовый клиент. У вас есть выбор.
И вы всегда можете написать свой собственный инструмент (или, возможно, настроить некоторые из существующих), чтобы лучше подобрать (каламбур) какое-то тестирование в вашей конкретной области интересов.
Еще одна общая мысль, это часто (не всегда !!!) лучше кодировать ваши тесты, «бизнес-правил» и просто о чем-либо, в какой-либо форме четко определенных данных, которые интерпретируют некоторые простые, общий фрагмент кода. Затем легко использовать данные другим способом: сгенерировать документацию, перенестись в новую среду тестирования, приложение порта на новую среду/язык программирования, использовать для проверки соответствия некоторым внешним правилам или другой системе (просто используйте свое воображение). Из этой информации гораздо сложнее извлечь такую информацию, например. простые жестко запрограммированные модульные тесты или бизнес-правила.
Fit хранит тестовые примеры в качестве данных. В очень специфическом формате из-за того, как он предназначен для использования, но все же. В ваших конкретных тестах могут использоваться разные форматы, такие как простые CSV, JSON или YAML (я не поклонник XML, подумал).
Как я писал это (слишком долго) обновление, я видел article by Gojko Adzic. Интересно, как люди пытаются программировать тесты в Fit/FitNesse, как если бы там, где язык программирования, который IMVHO просто побеждает цель.
Идея состоит в том, что вы (программист) определяете легко понятный формат, такой как лист excel. Затем владелец продукта вводит информацию, которая трудно понять для людей, которых нет в бизнесе ... и вы просто подтверждаете, что ваш код работает, поскольку PO ожидает выполнения Fit. Способ, используемый в xUnit, может использоваться для программистов в качестве входных данных для удобной для понимания или простой информации. Если вам понадобится ввести много странных примеров с несколькими полями в вашем тесте xUnit, это станет трудно читать.
Представьте себе случай, когда вам нужно решить, давать ли кредит клиенту в зависимости от возраста, женского/одиночного, количества детей, заработной платы, деятельности, ... Как программист, вы не можете написать, что Информация; и менеджер по рискам не может написать тест xUnit.
Помогает уменьшить избыточность при регрессии и тестировании ошибок. Создайте управляемый репозиторий тестовых примеров. Его как раз построить и использовать навсегда.