Kevin Wheatley wrote:
Unfortunately in my line if work we don't have very clear cut ideas for what we want, e.g. "make it look ghostly" isn't a good form for acceptance testing, but in the more standard parts of the business it is possible.
Requirements such as "make it look ghostly" just don't belong in the realm of code design. As a programmer you should never see such requirements. You are likely referring to game/entertainment development, in which such requirements are the responsibility of the artists, and the producer. But this is straying considerably off-topic now... So to bring it back. If we are talking about describing programming requirements they should be defined in terms of the language. To take some of Dean's examples: ==== int my_value = 0; //... value(my_value).should.equal(10); // will throw an exception value(my_value).should.not_equal(9); // will also throw an exception char * my_pointer = NULL; //... pointer(my_pointer).should.be_null(); // will evaluate to true, or do nothing pointer(my_pointer).should.not_be_null(); // will throw an exception ==== I would expect to more native syntax: ==== int my_value = 0; ensure( 10 == my_value ); ensure( 9 != my_value ); char * my_pointer = NULL ; ensure( NULL == my_pointer ); ensure( NULL != my_Pointer ); ==== Hence why I don't see the point of BDD when I'd rather have a contract definition framework. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo