Использование JUnit в качестве платформы приемочных испытаний

ОК, поэтому я работаю в компании, которая в последние годы открыто использует гибкие методы для развития. Наши модульные тесты и качество кода улучшаются. Одна из областей, над которыми мы все еще работаем, - это найти то, что лучше всего подходит для нас на арене автоматического приемочного испытания. Мы хотим использовать наши хорошо сформированные истории пользователей и использовать их для управления кодом в тестовом режиме. Это также даст нам тесты уровня принятия для каждой истории пользователей, которые мы затем можем автоматизировать.

На сегодняшний день мы пробовали Fit, Fitnesse и Selenium. У каждого есть свои преимущества, но у нас также были реальные проблемы с ними. С Fit и Fitnesse мы не можем не чувствовать, что они слишком сложны, и у нас было много технических проблем, связанных с ними. Бизнес не полностью купил в этих инструментах и не особенно увлекается постоянным сопровождением сценариев (и не являются большими поклонниками стиля таблицы). Селен действительно хорош, но медленный и зависит от данных и ресурсов в реальном времени.

Один из подходов, который мы сейчас рассматриваем, - использование структуры JUnit для обеспечения аналогичной функциональности. Вместо того, чтобы тестировать только небольшую единицу работы с помощью JUnit, почему бы не использовать ее для написания теста (с использованием структуры JUnit), чтобы охватить пропускную способность приложения? То есть возьмем новую историю ( "Как пользователь, которого я хотел бы увидеть основные сведения о моей политике..." ) и напишите тест в JUnit, который начинает выполнять код приложения в точке ввода ссылки на информацию о политике, но охватывает весь код и логику до уровня доступа с защищенным доступом к данным и обратно в точку пересылки на следующую страницу приложения, утверждая, какие данные пользователь должен видеть на этой странице.

Мне кажется, что у меня есть следующие преимущества:

Простота (не требуется никаких дополнительных фреймворков)
Нулевое усилие для интеграции с нашим сервером сборки Continuous Integration (поскольку он уже обрабатывает наши тесты JUnit)
Полный набор навыков уже присутствует в команде (это просто тест JUnit)

И нижние части:

Меньше привлечения клиентов (хотя они в значительной степени участвуют в написании рассказов пользователей в первую очередь, из которых будут записаны приемочные тесты)
Возможно, сложнее понять (или понять) пользовательскую историю и критерии приемлемости в классе JUnit, стихи спецификации freetext ala Fit или Fitnesse

Итак, мой вопрос действительно, вы когда-нибудь пробовали этот метод? Вы когда-нибудь считали это? Что ты думаешь? Что вам нравится и не нравится в этом подходе? Наконец, пожалуйста, обратите внимание только на альтернативные рамки, если вы можете сказать, почему вам нравится или не нравится больше, чем этот подход.

Ответ 1

Мой опыт использования JUnit для платформы тестирования приемки.

Наша компания сделала очень похожие вещи, где мы начали с FitNesse, а затем отправились в JUnit. Мы сделали это главным образом потому, что FitNesse уже сидел на вершине Java, поэтому переключение на JUnit было легко. FitNesse, казалось, не соответствовал (не каламбур) наших потребностей.

Вот мои плюсы и минусы использования JUnit:

Плюсы:

JUnit обладает большой гибкостью (потому что это Java), поэтому относительно легко создать Внутренний Домен специфический язык [Fowler]. DSL можно модифицировать так, чтобы пользователям домена (а не программистам) было легко читать/писать.
Так как JUnit вы можете использовать Eclipse в качестве среды IDE, которая дает вам автозаполнение, проверку синтаксиса, отладку и т.д.
Конкретно для нашего приложения у нас есть интерфейс CORBA для пользовательского интерфейса. Java также может легко использовать этот интерфейс CORBA.

Минусы:

Люди слышат JUnit и думают unit test. Это становится путаным, когда люди начинают ссылаться на приемочные тесты как "тесты JUnit".
Чтобы обеспечить упрощенную среду тестирования, вам нужно потратить некоторое время на расширение структуры и разработку вашей DSL.

Итак, JUnit отлично подходит для тестов Acceptance, если вы готовы потратить время, чтобы расширить его в своей собственной среде тестирования домена. В противном случае, я думаю, что я буду искать в другом месте что-то еще из коробки.

Ответ 2

Бизнес и UAT
Бизнес большую часть времени рано или поздно потеряет интерес к любому инструменту тестирования. В конце концов, это не тестеры для бизнеса, поэтому они не будут сильно посвящать написанию/поддержанию тестовых сценариев. Это бизнес, они хотят заниматься бизнесом. С их точки зрения, тестировщики/разработчики/другие ИТ-ребята несут ответственность за предоставление им программного обеспечения определенного качества.
Даже если Agile - это ваш путь, и вы получаете определенный уровень обязательств от бизнеса, не ожидайте, что они будут вести себя как тестер с каждым спринтом/итерацией или тем, что у вас есть. Это действительно не их работа. Одно отступление: Тесты приемки пользователей - это ручные тесты, выполняемые пользователем (ами), поэтому он (они) может сказать, является продуктом, о чем он (они) попросил.
Поэтому, когда функция (или набор функций) готова, делайте презентацию для бизнеса, позволяйте им играть с ней, пусть говорят, что это то, что им нужно. Не заставляйте их проверять эту функцию с каждой итерацией.

Теперь вернемся к вашим приемочным испытаниям. Всякий раз, когда у вас есть история от клиента, выполните тест для него в вашей тестовой инфраструктуре. Вы пишете его, вы его запускаете, вы его поддерживаете. Возможно, было бы разумно провести тест на разработку функций и дисков с помощью ADD/BDD/TDD или того, что вы хотите назвать. Это должно быть очевидно, что этот тест (ы), чем способствуют вашему набору регрессионных тестов в следующих итерациях.

Итак, моя точка зрения заключается в том, что Business не будет увлекаться написанием/поддержкой тестов, особенно когда набор функций растет. Не сражайтесь с ним, приспосабливайтесь к нему. Пусть они выполняют (вручную) тесты на прием пользователей в конце итерации для новых функций. Для себя создайте тесты для функций, которые они хотят иметь. Создайте приемочные тесты для каждой функции. Пусть эти тесты станут вашим регрессионным тестированием. Примите, что т - ваша ответственность за его поддержание.

Рамки приемочного тестирования
Юнит, да? Затем попробуйте с WatiJ для сети и Abbot для рабочего стола. Имейте в виду, что эти тесты не будут простыми модульными испытаниями. Вы хотите что-то, что будет проверять функции реального приложения, вы хотите, чтобы Test Script выполнял конкретный сценарий/бизнес-процесс. Это означает, что вам нужно подойти к написанию этих тестов, например, при написании приложения, которое они тестируют: DRY, KISS, YAGNI, Design Patterns - все применимо. В конце концов, он будет писать программное обеспечение, которое просто произойдет, чтобы протестировать другое программное обеспечение, которое вы пишете.

Станут ли эти тесты большими и сложными с таким подходом? Ну, больше и сложнее, чем модульные тесты. Но они не тестируют единое целое, а цельное приложение. Кроме того, они будут намного проще и меньше, чем приложение, которое вы пишете в первую очередь.

Будете ли вы писать структуру тестирования? Если вы хотите добиться успеха в этом подходе, чем да, вы будете писать тестовую структуру - сбор тестовых классов и вспомогательных классов, которые имеют некоторые знания о вашем приложении. Но вы не будете расширять JUnit. JUnit вот только некоторые API, которые вы используете в своей структуре.

Ответ 3

Несколько рекомендаций, если вы следуете этому пути:

Поместите ваши приемочные тесты в другой проект, так как, вероятно, они будут работать медленнее и иметь больше зависимостей, чем ваши обычные тесты.
Создайте сборщики (возможно, используя свободный интерфейс), чтобы настроить свою модель в тестовых приборах, потому что вы обнаружите, что настройка необходимых объектов для ваш тест будет самой скучной и трудной частью для поддержания.
Взгляните на Groovy и Spock Framework: он совместим с JUnit, но предоставляет вам приятную DSL, чтобы сделать вашу читаемые тесты.

Ответ 4

Попробуйте robotframework (www.robotframework.org), я использую его в течение многих лет, Pekka Klarck из Хельсинки разработал его (Nokia Siemens Networks поддерживает его с самого начала, теперь он также открывается из источников).

robotframework использует тестовые примеры табличного формата, поддерживающие HTML, CSV или обычный текст (написанный в определенном грамматике). Он имеет библиотечный механизм, который поддерживает импорт функций Selenium. Вы можете написать библиотеку для robotframework в Python или Java.

Для JUnit в качестве платформы тестирования приемочных испытаний, конечно, вы можете, но это не стоит делать. Тестирование на более высоком уровне должно быть намного меньше, чем во внутренней реализации программного обеспечения, в то время как приемочный тест записи с использованием JUnit (который представляет собой структуру unit test), вы ввели множество зависимостей от его, например, внутренние вызовы функций. Который будет большой головной болью, в то время как при разработке программного обеспечения происходят какие-либо изменения, на которые не следует влиять тест высокого уровня, и вы.

Ответ 5

Совершенно справедливо использовать JUnit для написания приемочных тестов. JUnit - это всего лишь платформа выполнения тестов, совершенно неважно, выполняете ли вы на самом деле с ним единичные тесты, тесты компонентов, тесты интеграции или приемочные тесты. Поскольку user1704737 уже сказал, важно, чтобы у вас была читаемая DSL для написания ваших тестов.

Чтобы написать вам тесты в JUnit, я предлагаю попробовать JGiven. Это легкая структура, облегчающая запись приемочных тестов в формате "когда-то" в простой Java. Он использует JUnit (или TestNG) в качестве тестового исполнителя, так что его можно легко интегрировать в существующие тестовые инфраструктуры. Вы также получаете отчеты HTML для своих приемочных испытаний, которые вы можете показать бизнесу для проверки тестов на соответствие требованиям.

Отказ от ответственности: я являюсь автором JGiven

Ответ 6

Вы упомянули о хороших моментах о плюсах и минусах. Могу ли я добавить:

Upsides: Мне нравится идея проверить все, не имея базы данных, веб-сервера. Это очень помогает в понимании кода и в рефакторинге.

Downsides:

Код JUnit будет сложным и трудноподдерживаемым. Вам нужно будет воспроизвести все взаимодействия между кодом и пользователем в тесте Junit, который очень быстро становится сложным. Если все, что вы делаете, это тестирование одной точки входа, то это может сработать, но если вы тестируете несколько экранов (мастер или что-то в этом роде), тогда он может быстро стать хрупким и неуправляемым. Проблема в моем опыте - это почти всегда код сантехники между страницами или код установки, необходимый для страницы.

Еще одна вещь, которую следует учитывать, - это гибкость того, что вы пытаетесь сделать. С Fitnesse довольно легко добавить еще один тест, если вы обнаружите ошибку. На самом деле, это идея Fitnesse: "пользователь" может добавить еще один тест, не изменяя код. Не стоит недооценивать значение этого.

Итак, я бы предложил две вещи:

1) Попробуйте. Возьмите рассказ пользователя (не слишком сложный, не слишком простой), и сделайте это в JUnit. Сравните то, что вы сделали с Selenium/Fitnesse и т.д., И посмотрите, стоит ли это. Посмотрите, если вы 1. на самом деле находите ошибки, 2. производите хрупкий, трудно управляемый код.

2) Не могли бы вы использовать данные, созданные Fitnesse, в качестве входных данных для ваших тестов JUnit (таким образом, устраняя необходимость в веб-сервере и т.д.). Вы могли бы прочитать данные и вызвать методы в Java-классах напрямую. Опять же, у вас могут быть проблемы с настройкой и кодом базы данных.

Ответ 7

ИМХО Не очень хорошая идея. Помимо 2 минус, о которых вы упомянули, как насчет огромных усилий, необходимых для создания платформы приемочных испытаний, которая будет обрабатывать все типы сценариев веб-интерфейса/UI/клей, которые у вас могут быть? Ваш вопрос "Простота (никаких дополнительных фреймворков не требуется)" является неправильным, так как вашей организации придется инвестировать в создание более сложной структуры поверх JUnit. Это может быть больше, чем JUnit.