Fitnesse - можем ли мы разбить большую таблицу, которая зависит от множества значений, но не имеет промежуточного результата?

Question

Я только начал работать с фитнесом за последний месяц или около того.

У меня есть около 50-60 различных входов, которые будут влиять на результат. До сих пор мне не удалось найти какие-либо промежуточные результаты, которые я мог бы зафиксировать и отложить.

Принимая во внимание пример расчета скидки, существует ряд значений, которые необходимо зафиксировать в мастере из трех или четырех страниц. Затем они будут использованы для расчета скидки. Однако существует один сервис, который принимает все входные данные и рассчитывает скидку. Компоненты расчета скидки также должны быть проиллюстрированы.

В качестве конкретного примера, скажем, пользователь может выбрать любой или все параметры A, B, C в пользовательском интерфейсе, и у каждого параметра есть определенные связанные значения, которые пользователь вводит в мастере, которые входят в расчет скидки. Не все параметры могут быть связаны со всеми свойствами. Мой фитнес-стол должен выглядеть так:

             Property A     Property B        Property C   Expected value
   Option A        5                6                n/a          5
   Option B       n/a              n/a               10          2
   Option C       10               n/a               10          3

(н / д указывает, что свойство не применимо к этой опции)

Проблема здесь в том, что у меня есть одна вызываемая служба, которую нельзя изменить, которая будет принимать весь набор выбранных параметров и свойств и возвращать общую скидку, а также отдельные компоненты скидки для каждой опции. выбран. Пользователи ожидают, что отдельные компоненты также будут проверены на странице соответствия.

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

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

Заранее спасибо !!

спасибо, SUBU

Answer 1

Один из вариантов, над которым я работал, - это определение собственных подстолей:

Main Table

 SubTable:com.test.Table1
                   Property1         Property2   
      Option A      5                    6
      Option D      10                   7

 SubTable:com.test.Table2
                    Property3         Property4
      Option B       12                n/a
      Option C       15                 10

MainTable - это фактическая таблица пригодности.«SubTable» - это просто строка, которую я использую в качестве разделителя между моими вложенными таблицами, чтобы найти начало новой вложенной таблицы.Следуя «SubTable», я могу пойти по универсальному маршруту и ​​определить класс, который должен быть создан, чтобы справиться с этим.

Для того, чтобы сохранить как универсальный, так и как можно ближе к обычной пригодности, subклассы таблиц также должны вести себя точно так же, как обычные таблицы фитнеса, с методом doTable ().

Это логика в MainTable.java - анализировать отдельные строки, группировать их в подтаблицы,создавать экземпляры отдельных классов обработки с помощью отражения и передавать строки в вызов doTable ().Вложенная таблица затем выполнит собственную логику и проверку, а затем вернет строки прохождения / неудачи.Затем MainTable.java будет сопоставлять все результаты, возвращаемые всеми вложенными таблицами, и отображать их.

Пока что это работает для меня.Разброс столбцов значительно уменьшается при условии правильной группировки строк подтаблицы.

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