Rene Rivera wrote:
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:
I think I agree that the should.equal() part may be better expressed at equals() (Law of Demeter style) but its context specific, so perhaps a wider interface is called for to improve the expressiveness.
==== 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.
I think in the cases here yours is a simple assert equivalent and I agree you don't need Dean's form to make meaningful descriptions. Slightly more complicated is something like: my_value = 6; value(my_value).is_between(5).and(7); so now we have a point of discussion... ensure((my_value > 5) and (my_value < 7)); or is it ensure((my_value >= 5) and (my_value <= 7)); i.e. it doesn't express clearly in English if the range is open/closed/half open. Not unless we have more information about the domain, perhaps it should be better expressed: day_of_week = Saturday; ensure_that(day_of_week).is_between(Friday).and(Sunday); or ensure_that(Saturday).is_between(Friday).and(Sunday); If the language allowed for aspects say you could even be tempted to allow Saturday.is_between(Friday).and(Sunday); keep going and you'd probably get to Ruby :-) Another thing that is interesting is the possibility of expressing things like: my_thing.set_something_or_other(); value(my_thing).is_not_empty(); value(it).has_some_other_property(); where 'it' is magical and takes on a reference to the object under specification, but I'm fairly sure C++ can't do that without some other tool's assistance, i.e. its not capable of being expressed in the language as-is, nor as some pseudo DSL construct. My end point would be that a BDD framework would be helpful if it could provide a wide enough set of expressions to allow the users to interact with the developers in an improved way. [OT bit follows] As to the ghostly reference, it was for a visual effect for a film and the request came from an artist to a developer, in this case it was important that the two work directly to express the requirements and not have 2-3 layers of interpretation between them. "make it look ghostly" might be the name of a test suite or behavioral description suite/acceptance tests essentially a starting point for ubiquitous language. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |