{ given “a VIP customer”
and “given they have at least 3 items”
and “the 3 items total at least $x”
x = 30 => scenario “VIP customer with 3 items, over $30 receiving 10% discount” { then “they should receive a 10% discount” }
x = 100 => scenario “VIP customer with 3 items, over $100 receiving 15% discount” { then “they should receive a 10% discount” } }

I was really hoping you had a good use case for avoiding DRY - I’ve been wondering whether there are any.

Incidentally, I’d rather write the code this way:

customers filter (customer => customer.isVip && customer.items.size == 3) all (customer => HashMap(100 -> 15, 30 -> 10).highestLessThan(customer.items.price) == customer.items.discount)

EasyB is terrifically easy to learn and it isn’t difficult to teach someone about set-ups and tear downs.
Maybe an EasyB scenario ‘constant’ or ’set’ could be created so a well named variable could be used rather than a set up so a customer/BA can still understand and you don’t abuse the DRY principle?

How about WET = wholly express the tale?

The DRY principle—”Don’t repeat yourself”—of the Pragmatic Programmers (http://www.pragmaticprogrammer.com) should be applied to test code in the same way it is applied to production code. There is, however, a counterforce at play. Because the tests should Communicate Intent, it is best to keep the core test logic in each Test Method so it can be seen in one place. Nevertheless, this idea doesn’t preclude moving a lot of supporting code into Test Utility Methods, where it needs to be modified in only one place if it is affected by a change in the SUT.

Really nice tips!

will try to keep it in my mind

thanks!