Использование JUnit в качестве основы приемочного тестирования

Question

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

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

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

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

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

И минусы:

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

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

Answer 1

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

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

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

Плюсы:

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

Минусы:

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

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

Answer 2

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

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

Отказ от ответственности: я автор JGiven

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

Downsides:

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

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

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

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

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

Answer 7

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