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