Comments on: It’s ok to wet yourself every once in awhile

By: Ricky Clarkson

Ricky Clarkson — Sat, 19 Jul 2008 19:09:50 +0000

I could probably come up with more accessible syntax than that, but I’d need to try it out on some non-geeks. Sadly, my girlfriend already understands Scheme syntax (took about 2 minutes), so that’s her out. And most other people I know can already use Excel, so they could cope with the above syntax given an explanation. Damn.

By: Andy

Andy — Fri, 18 Jul 2008 20:01:42 +0000

Ricky- your code: customers filter (customer => customer.isVip && customer.items.size == 3) all (customer => HashMap(100 -> 15, 30 -> 10).highestLessThan(customer.items.price) == customer.items.discount) is slick, baby; however, it isn’t very friendly to non-geeks (which may or may not be a concern!!). Thanks for sharing!

By: Andy

Andy — Fri, 18 Jul 2008 19:59:38 +0000

Rich- you know, you are on to something with a well named constant– that is a feature that we’ve played with and it has come up before. Point well taken, friend!

By: Andy

Andy — Mon, 14 Jul 2008 17:18:55 +0000

Clint- Yeah, I think you are right– tale is good. WET = Wholly express the tale is my bag, baby.

By: Ricky Clarkson

Ricky Clarkson — Wed, 02 Jul 2008 22:04:53 +0000

I don’t even know which language the above is written in, so please bear my made-up syntax:

{ 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)

By: Rich Sharpe

Rich Sharpe — Wed, 02 Jul 2008 17:22:41 +0000

I can see how this could be a benefit in easyB. - Anything that can eliminate ambiguity from the BA’s writing easyB stories is a good thing.
However if one of your statements is wrong you still have to go and change all occurrences - are you going to find them all?

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?

By: Clint Shank

Clint Shank — Wed, 02 Jul 2008 15:53:21 +0000

I’m not sure I like the word “tactics”. It sounds like it may refer to implementation details.

How about WET = wholly express the tale?

By: Philip Schwarz

Philip Schwarz — Wed, 02 Jul 2008 12:44:12 +0000

Gerard Meszaros in XUnit Test Patterns - Refactoring Test Code:

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.