Должны ли ожидаемые результаты E2E-тестов быть жестко закодированы или рассчитаны?JAVA

Программисты JAVA общаются здесь
Ответить Пред. темаСлед. тема
Anonymous
 Должны ли ожидаемые результаты E2E-тестов быть жестко закодированы или рассчитаны?

Сообщение Anonymous »


Я инженер BE и имею опыт модульного тестирования BE, но недавно начал работать над сквозными тестами FE, используя Playwright и Cucumber. Должен ли ожидаемый результат сценария быть жестко запрограммированным примером или его следует рассчитывать в рамках теста?

Для упрощения предположим, что я пытаюсь написать тест скидки на сайте электронной коммерции и пишу тест для проверки правильности суммы скидки. Он принимает общую сумму корзины пользователя в качестве входных данных и выполняет расчет на стороне клиента, чтобы применить фиксированную скидку 12%, и возвращает результат пользователю. Должен ли я рассчитывать эти 12% в рамках определений этапов теста? Или мне следует жестко запрограммировать ожидаемый результат? Файл функций выглядел бы примерно так, если бы я жестко запрограммировал ожидаемый результат:

Сценарий: проверка правильности суммы скидки Учитывая сумму в корзине покупок, 60,00. Когда я нажимаю «Рассчитать скидку» Тогда сокращение должно составить 7,20. Или следует изменить последнюю строку, чтобы вычислить ее следующим образом: Тогда сокращение должно быть таким, как ожидалось, а файл определения шага делает что-то вроде

@Then("Уменьшение должно быть таким, как ожидалось") общественный недействительный theReductionShouldBe () { двойной фактический = getReductionDisplayedToUser(); двойное ожидаемое = общая корзина * 0,12; AssertEquals (ожидаемое, фактическое); } На самом деле расчет для инструмента, который я тестирую, сложнее, чем просто вычисление 12% (имеется несколько входных данных вместо одного), поэтому моя проблема с последним заключается в том, что я дублирую всю логику в своем Репозиторий для тестирования e2e. Но есть аргумент, что если логика изменится, мне не нужно трогать свой файл функций, и я могу просто обновить логику в расчете. Лично я предпочитаю первый вариант, поскольку он похож на стиль тестирования моих модульных тестов BE, но не уверен, что это лучшая практика для E2E-тестов.

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

Сценарий: проверка правильности суммы скидки Учитывая, что общая сумма корзины покупок представляет собой случайную сумму от 0,00 до 1000,00. Когда я нажимаю «Рассчитать скидку» Тогда сокращение должно быть ожидаемым. Как я уже сказал, я новичок в тестировании E2E и не уверен, существуют ли в этом отношении какие-либо стандарты или лучшие практики. Есть мысли?
Реклама
Ответить Пред. темаСлед. тема

Быстрый ответ

Изменение регистра текста: 
Смайлики
:) :( :oops: :roll: :wink: :muza: :clever: :sorry: :angel: :read: *x)
Ещё смайлики…
   
К этому ответу прикреплено по крайней мере одно вложение.

Если вы не хотите добавлять вложения, оставьте поля пустыми.

Максимально разрешённый размер вложения: 15 МБ.

  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «JAVA»