Используя JUnit как платформа приемочного испытания
Хорошо, таким образом, я работаю на компанию, которая открыто приняла гибкие методы для разработки в последние годы. Наши модульные тесты и качество кода улучшаются. Одна область мы все еще продолжаем работать, должна найти что работы лучше всего для нас на автоматизированной арене приемочного испытания. Мы хотим взять наши хорошо сформированные пользовательские истории и использовать их для управления кодом в тесте управляемый способ. Это также даст нам приемные тесты уровня для каждой пользовательской истории, которую мы можем затем автоматизировать.
До настоящего времени мы попробовали Соответствие, Fitnesse и Selenium. У каждого есть их преимущества, но у нас также были реальные проблемы с ними также. С Fit и Fitnesse, мы не можем не чувствовать, что они сверхусложняют вещи, и у нас было много технических вопросов с помощью них. Бизнес не полностью купил в этих инструментах и не особенно увлечен поддержанием сценариев все время (и не большие поклонники стиля таблицы). Селен является действительно хорошим, но медленным и полагается на данные реального времени и ресурсы.
Один подход, который мы теперь рассматриваем, является использованием платформы JUnit для обеспечения подобной функциональности. Вместо того, чтобы тестировать просто небольшую единицу работы с помощью JUnit, почему бы не использовать его для записи теста (использующий платформу JUnit) для покрытия приемного ряда уровня приложения? Т.е. возьмите новую историю ("Как пользователь, я хотел бы видеть основные детали своей политики..."), и запишите тест в JUnit, который начинает выполнять код приложения при записи для ссылки деталей политики, но покрывает весь код и логику вниз к заблокированному уровню доступа к данным и назад на грани передачи следующей странице в приложении, утверждая на том, какие данные пользователь должен видеть на той странице.
Это, кажется, мне имеет следующие преимущества:
- Простота (никакие дополнительные требуемые платформы)
- Нулевое усилие интегрироваться с нашей Непрерывной Интеграцией создает сервер (так как это уже обрабатывает наши тесты JUnit),
- Полный набор навыков, уже существующий в команде (ее просто JUnit тестируют, в конце концов),
И оборотная сторона быть:
- Меньше клиентского участия (хотя они в большой степени включены в письменной форме пользовательские истории во-первых, из которых приемочные испытания будут записаны),
- Возможно, более трудный понять (или заставить понять) пользовательская история и критерии допустимости в классе JUnit стихи freetext крыло спецификации Fit или Fitnesse
Так, мой вопрос действительно, Вы когда-либо пробовали этот метод? Когда-нибудь рассмотренный им? Каковы Ваши мысли? Что Вы любите и не любите об этом подходе? Наконец, только упомяните альтернативные платформы, если можно сказать, почему Вы любите или не любите их больше, чем этот подход.
3 ответа
ИМХО Плохая идея. Помимо двух упомянутых вами минусов, как насчет огромных усилий, необходимых для создания инфраструктуры приемочного тестирования, которая будет иметь дело со всеми типами сценариев веб / пользовательского интерфейса / склейки, которые могут у вас возникнуть? Ваш пункт "Простота (дополнительных фреймворков не требуется)" неверен, поскольку вашей организации придется вложить средства в создание более сложной структуры поверх JUnit. Это может быть больше, чем JUnit.
Вы упомянули несколько хороших моментов о плюсах и минусах. Могу я добавить:
Плюсы: мне нравится идея тестировать все, не имея базы данных, веб-сервера. Это очень помогает в понимании кода и рефакторинге.
Недостатки:
Код JUnit будет сложным и трудным в поддержке. Вам нужно будет воспроизвести все взаимодействия между кодом и пользователем в рамках теста Junit, который очень быстро становится сложным. Если все, что вы делаете, - это тестируете одну единственную точку входа, то это вполне может сработать, но если вы тестируете несколько экранов (мастер или что-то в этом роде), тогда он может быстро стать хрупким и неуправляемым. По моему опыту, проблема почти всегда заключается в соединительном коде между страницами или в установочном коде, необходимом для страницы.
Еще одна вещь, которую следует учитывать, - это гибкость того, что вы пытаетесь сделать. С Fitnesse довольно легко добавить еще один тест, если вы обнаружите ошибку. Фактически, это идея Fitnesse: «пользователь» может добавить еще один тест, не меняя код. Не стоит недооценивать ценность этого.
Я бы предложил две вещи:
1) Попробуйте. Возьмите пользовательскую историю (не слишком сложную, не слишком простую) и сделайте это в JUnit. Сравните то, что вы сделали с Selenium / Fitnesse и т. Д., И посмотрите, стоит ли это того. Посмотрите, действительно ли вы 1. находите ошибки, 2. создаете хрупкий, трудно управляемый код.
2) Можете ли вы использовать данные, созданные Fitnesse, в качестве входных данных для ваших тестов JUnit (таким образом устраняя необходимость в веб-сервере и т. Д.). Вы могли бы читать данные и напрямую вызывать методы в классах Java.Опять же, у вас могут возникнуть проблемы с настройкой и кодом базы данных.
Бизнес и UAT
Бизнес в большинстве случаев рано или поздно потеряет интерес к любому инструменту тестирования. В конце концов, они бизнесмены, а не тестировщики, поэтому они не будут уделять много внимания написанию/поддержанию тестовых сценариев. Они бизнесмены, они хотят делать бизнес. С их точки зрения, тестировщики/разработчики/другие ИТ-специалисты ответственны за предоставление им программного обеспечения определенного качества.
Даже если Agile - это ваш путь, и вы получили определенный уровень обязательств от бизнеса, не ожидайте, что они будут вести себя как тестировщики в каждом спринте/итерации или что там у вас есть. Это действительно не их работа.
Одно отступление: Приемочные тесты пользователя - это ручные тесты, выполняемые пользователем (пользователями), чтобы он (они) мог (могли) сказать, что продукт соответствует его (их) запросам.
Поэтому, когда функция (или набор функций) готова, сделайте презентацию для бизнеса, дайте им поиграть с ней, пусть они скажут, то ли это, что им нужно. Не заставляйте их проверять эту функцию на каждой итерации.
Теперь вернемся к вашим приемочным тестам. Всякий раз, когда у вас есть история от клиента, реализуйте тест(ы) для нее в вашей тестовой инфраструктуре. Вы пишете его, запускаете его, поддерживаете его. Может быть разумно иметь тесты для функций и вести разработку с помощью ADD/BDD/TDD или как вы хотите это назвать. Должно быть очевидно, что этот тест(ы) внесет свой вклад в набор регрессионных тестов в следующих итерациях.
Так что моя точка зрения такова: бизнес не будет стремиться писать/поддерживать тесты, особенно когда набор функций растет. Не боритесь с этим, адаптируйтесь к этому. Пусть они делают только (ручные) приемочные тесты пользователей в конце итерации для новых функций. Для вашего же блага создавайте тесты для функций, которые они хотят иметь. Создавайте приемочные тесты для каждой функции. Пусть эти тесты станут вашим костюмом для регрессионного тестирования. Примите, что вы несете ответственность за его поддержку.
Framework для приемочного тестирования
JUnit, да? Тогда попробуйте использовать WatiJ для веб, и Abbot для десктопа. Имейте в виду, что эти тесты не будут простыми юнит-тестами. Вам нужно что-то, что будет тестировать возможности реального приложения, вам нужен тестовый сценарий для выполнения определенного сценария/бизнес-процесса. Это означает, что вам нужно подойти к написанию этих тестов так же, как к написанию приложения, которое они тестируют: DRY, KISS, YAGNI, Design Patterns - все применимо. В конце концов, это будет написание программного обеспечения, которое просто тестирует другое программное обеспечение, которое вы пишете.
Станут ли эти тесты большими и сложными при таком подходе? Ну, больше и сложнее, чем модульные тесты. Но они тестируют не отдельный модуль, а целое приложение. Кроме того, они будут намного проще и меньше, чем приложение, которое вы пишете в первую очередь.
Будете ли вы писать фреймворк для тестирования? Если вы хотите преуспеть с этим подходом, то да, вы будете писать фреймворк тестирования - коллекцию тестовых классов и классов-помощников, в которых реализованы некоторые знания о вашем приложении. Но вы не будете расширять JUnit. JUnit здесь - это просто некий API, который вы используете в своем фреймворке.