Архитектура тестов Java + FitNesse

общие вопросы
#1

Добрый день коллеги. Тема несколько размытая, но проблема у меня серьезная. Итак на том проекте, на котором я сейчас работаю - тест-дизайн пишется напрямую в FitNesse (я пытаюсь с этим бороться, но это длительный процесс). Тесты пишет человек практически с нулевым техническим background. Имеется тьма-тьмущая методов, в разных классах (зависит от типа реализуемой fixtures. И я и тест-дизайнер уже плаваем во всем этом изобилии. А я все никак не могу придумать, как же мне пере-использовать код, или хотя бы WebElements. Применить PageObject, хотелось бы - но при этом я должен оставить имеющиеся наименования методов и зеленые тесты. У кого какие мысли по этому поводу.

1 лайк
#2

Как пример, у меня есть один класс в который запихано больше 150 методов, банальных, тривиальных. Но они вызываются в FitNesse. В этом есть еще один ньюанс, я не не знаю когда и с какими параметрами, будет вызыван метод.

#3

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

Ну а пока можно писать нормальный фреймворк, с переиспользованием кода, а те методы, которые сейчас в тестах дергаются, чтоб просто вызывали методы “правильного фреймворка”, то есть работали как прокси (до тех пор пока тест-дизайнер не отрефакторит на прямой вызов).

Мне кажется всю проблему надо разбить на части. Сейчас для тебя эта задача выглядит монолитной (судя по вопросу). Декомпозируй.

#4

Приведите пример кода/псевдокода - у меня в голове картинка как-то не вырисовывается, особенно с тривиальными 150+ методами в одном классе.

#5

А что тут вырисовывать…

attributeIsDisplayed()
clickAddLogicalOperatorButtonForCustomFilterTreeItem(int)
clickColumnsForResultButtonCaret()
clickExportResultButton()
clickFiltersButtonPlus()

Примерно так, куча таких методов

#6

Да, буду разбивать на части. Фактически главная проблема в FitNesee - то что он все сразу:

  1. Хранение требований
  2. Запуск тестов
  3. Написание и хранение тестов
  4. Вывод отчетов
    И все это он делает, одинаково не очень хорошо
#7

Перечень выглядит как достоинства.
Архитектура BDD, всегда требует дополнительных вложений в плане кода, каких-либо “признанных” решений без напильника - я не видел.

#8

Для каждой из этих задач, есть инструменты - которые справляются лучше.