Not sure if this falls into the useful or into the weird category, but I’m beginning to do code generation in my behavior specifications…

Take a look at the behavior specification:

And the corresponding implementation:

Nothing too earth shattering, except for the specs. How do I ensure the specs were properly generated ? I didn’t, except for confirming that the number of tests and assertions went up as expected.

2 Responses to “Using code generation in tests”

  1. Anonymous Coward Says:

    That code sure smells Enterprisey to me. It looks like you’re jumping through a lot of hoops just to assert that “approved” == “approved” and “approved” != “started”.

    Is TransactionStateOrderingTest really testing something that might break? In fact, is TransactionState any more useful than StatusNames would be on it’s own?

  2. François Says:

    Sure, TransactionState allows me to encapsulate ordering calculations. That way, Transaction doesn’t need to know about it.

    I knew it smelled… Probably time to change that diaper.

Leave a Reply

 

Search

A picture of me

I am François Beausoleil, a Ruby on Rails coder. During the day, I work on XLsuite. At night, I am interested many things. Read my biography

Tags

(4) (1) (1) (1) (1) (2) (1) (1) (1) (2) (2) (1) (2) (1) (3) (1) (2) (1) (1) (1) (1) (2) (14) (1) (1) (1) (1) (2) (1) (1) (2) (0) (1) (4) (1) (3) (1) (1) (1) (1) (1) (1) (0) (3) (2) (1) (2) (1) (3) (1) (5) (2) (10) (10) (11) (14) (2) (1) (3) (1) (1) (1) (1) (1) (0) (1) (2) (2) (2) (1) (1) (1) (4) (1) (3) (1) (4) (2) (2) (25) (2) (1) (1) (0) (1) (1) (1) (23) (25) (1) (1) (13) (1) (1) (1) (4) (5) (1) (1) (1) (4) (1) (2) (3) (4) (4) (1) (1) (1) (8) (3) (1) (5) (5) (2) (2) (2) (4) (8) (7) (1) (1) (1) (1) (2) (4) (1) (4) (12) (2) (1) (2) (4) (1) (1) (1) (2) (8) (2) (3) (2) (2) (1) (3) (1) (1)

Links

Projects I work on

Categories

Archives