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

Question

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

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

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

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

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

И отрицательные стороны являются:

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

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

Answer 1

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

Answer 2

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

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

Downsides:

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

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

Так что я хотел бы предложить две вещи:

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

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

Плюсы:

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

Минусы:

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

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

Answer 7

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

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

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