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