Весь смысл в том, чтобы работать с непрограммистами, часто даже с совершенно нетехническими людьми, такими как потенциальные пользователи бизнес-приложений, над тем, что приложение должно делать, а затем подвергать его тестированию. Хотя выполнение тестов для них, безусловно, слишком сложно, они должны иметь возможность обсуждать таблицы с образцами данных, заполненными, например, Слово. И что самое приятное, в отличие от традиционных спецификаций, эти документы соответствуют вашему приложению, потому что автоматизированные тесты вынуждают их обновлять.
См. Введение в Fit и Fit Workflow by James Shore и, если хотите, следуйте ссылкам на остальную документацию.
Обновление: Зависит от того, что вы подразумеваете под бизнес-правилами? ;-) Некоторые люди поняли бы это очень узко (как в двигателях бизнес-правил и т. Д.), Другие - очень широко.
На мой взгляд, Fit - это инструмент, который позволяет записывать бизнес-сценарии (как в домене) с богатым реалистическим примером в документе, который конечные пользователи или эксперты по доменам (в некоторых доменах) могут понять, проверить и обсудить. В то же время эти примеры представлены в машиночитаемом виде, поэтому их можно использовать для автоматизированного тестирования. Вы не пишете документ самостоятельно и не запрашиваете его для этого. Вместо этого это продукт совместной работы и обсуждения, который отражает растущее понимание того, что приложение собирается делать, с обеих сторон. Примеры становятся богаче по мере вашего продвижения, и решается больше угловых дел.
Важно то, что будет делать приложение, а не как. Это форма функциональной спецификации. Как таковой, он довольно широк и не организован по модулям, а скорее по сценариям использования.
Тесты, которые вышли из примеров, будут проверять внешнее поведение приложения в аспектах, важных с деловой точки зрения. Да, вы можете назвать это бизнес-правилами. Но давайте взглянем на пример кредитного скоринга Диего Янчича, просто с небольшим поворотом. Что делать, если частью документа соответствия является 1) перечисление атрибутов и их оценок, а затем 2) предоставление клиентских данных и результатов проверки. Тогда каковы фактические бизнес-правила: таблица оценки (атрибуты и их оценки) или логика приложения, вычисляющая оценку для каждого клиента (на основании таблицы баллов)? А какие проверены?
Тесты Fit / FitNesse кажутся более подходящими для приемочных испытаний. Другие тесты (когда вы не заботитесь о сотрудничестве с клиентами, пользователями, экспертами по доменам и т. Д., Вы просто хотите автоматизировать тестирование), вероятно, будет проще написать и поддерживать более традиционными способами. xUnit хорош для модульного тестирования и API-тестов. Каждая веб-платформа должна иметь некоторый инструмент для тестирования веб-приложений / сервисов, интегрированный в свой цикл modify-build-test-deploy, например. У django есть маленький тестовый клиент. Вам есть из чего выбирать.
И вы всегда можете написать свой собственный инструмент (или, желательно, настроить некоторые из существующих), чтобы лучше соответствовать (каламбур) некоторому тестированию в вашей конкретной области интересов.
Еще одна общая мысль. Часто (не всегда !!!) лучше кодировать ваши тесты, «бизнес-правила» и все, что угодно, в какой-то форме четко определенных данных, которые интерпретируются с помощью некоторого простого, обобщенного фрагмента кода. Тогда эти данные легко использовать другим способом: создавать документацию, переходить на новую среду тестирования, переносить приложение на новую среду / язык программирования, использовать для проверки соответствия каким-либо внешним правилам или другой системе (просто используйте свое воображение). Гораздо сложнее извлечь такую информацию из кода, например. простые жестко закодированные модульные тесты или бизнес-правила.
Fit сохраняет контрольные примеры в виде данных. В очень специфическом формате из-за того, как он предназначен для использования, но все же. Тесты, специфичные для вашего домена, могут использовать различные форматы, такие как простые CSV, JSON или YAML.