Interest in a Behavior Driven Development Framework
Hi Everyone, I've been mulling around having watched this video ( http://tinyurl.com/kywhy ) about Behavior Driven Development ( http://tinyurl.com/jzbcb ). I've been practicing TDD for a while now, and it (BDD) seems like a more "intuitive" and readable alternative to the "assert*" way of specifying behavior. I was on the way to writing something quick to use in a project in-house, and thought out loud: would the Boost community be interested in having something like this alongside or built upon the already existing testing framework? I had been thinking about the syntax to which the BDD approach allows us: 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 where value(my_value) is defined as (untested): template <typename T> spec<T> value ( const T & v ) { return spec<T>(v); }; where spec<> is defined as (untested): template <typename T> struct spec { T value; should_impl<T> should(value); }; and should_impl<> is defined as (untested): template <typename T> struct should_impl { T & _value; should_impl(T & value) : _value(value); template <typename ArgType> bool equal (const ArgType & expected) const { if (_value == expected) return true; throw not_equal_exception<T, ArgType>(_value, expected); }; template <typename ArgType> bool not_equal (const ArgType & expected) const { if (_value != expected) return true; throw are_equal_exception<T, ArgType> (_value, expected); }; }; Which would entail the use of some of the Boost.MPL for some of the type-safeness magic required to determine if the value being scrutinized (i don't want to say tested) is a pointer, a reference, or an instance among other things. I'm writing this message off the top of my head and even before I start writing the framework for an internal project; so I'd like to know if anybody is interested in something like this. (After all, I'd like to know if there is enough interest so that I can write it from scratch to comply with the Boost Library requirements in mind already). ;) Have a great day everyone, and hope to hear from you soon! -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
Dean Michael Berris wrote:
I had been thinking about the syntax to which the BDD approach allows us:
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
What's the added value of the above when compared to: value_should_equal(my_value, 10); value_should_not_equal(my_value, 9); pointer_should_be_null(my_pointer); pointer_should_not_be_null(my_pointer); or maybe: should_equal(my_value, 10); should_not_equal(my_value, 9); should_be_null(my_pointer); should_not_be_null(my_pointer); ? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/
Hi Maciej, On 9/14/06, Maciej Sobczak <prog@msobczak.com> wrote:
What's the added value of the above when compared to:
value_should_equal(my_value, 10); value_should_not_equal(my_value, 9); pointer_should_be_null(my_pointer); pointer_should_not_be_null(my_pointer);
or maybe:
should_equal(my_value, 10); should_not_equal(my_value, 9); should_be_null(my_pointer); should_not_be_null(my_pointer);
The added value I suppose would be the ability to store the spec<> objects and even extend the specifications later. Consider having the ability to wrap the spec<> object and decorating it to do something else later -- specially making it more type-safe, and more intuitive to use. The problem with the above examples are that you need to remember which one is the value being tested, and which one is the expected result. Having something like value(a).should.equal(10); or perhaps: spec<int> return_value = value(a); // ... return_value.should.be_less_than(10); return_value.should.be_more_than(5); vector<std::string> my_vector; // ... container(my_vector).should.contain("my_type"); container(my_vector).should.have_size(10); If the spec<> type derived from a parametric base class dependent on the parameter to spec, perhaps other specifications can be defined and added later. The design of the library will greatly benefit in terms of flexibility, without having to get stuck with just plain methods that might be too hard to extend. HTH... -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
"Dean Michael Berris" <mikhailberis@gmail.com> writes:
Hi Everyone,
I've been mulling around having watched this video ( http://tinyurl.com/kywhy ) about Behavior Driven Development ( http://tinyurl.com/jzbcb ). I've been practicing TDD for a while now, and it (BDD) seems like a more "intuitive" and readable alternative to the "assert*" way of specifying behavior.
Watching the video about 25% through, so far I don't get what he's talking about or why BDD is different from what I do anyway or how it can benefit me. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hi Dave! On 9/14/06, David Abrahams <dave@boost-consulting.com> wrote:
Watching the video about 25% through, so far I don't get what he's talking about or why BDD is different from what I do anyway or how it can benefit me.
It's really just a "clarification" of Test Driven Development. The gist is as follows: * Instead of emphasizing on "Tests", you emphasize "Specification". * The assert_* line of methods leans on the "testing" and "invalidation" of results and values. The language used is also not very clear when using it to specify behaviour. * Specifications are made more readable. They have an implementation in Ruby called `RSpec' which uses a more readable framework than `assert_something(value_tested, expected_value)' -- you can look at http://rspec.rubyforge.org/ for more information on that. It's not different from TDD, but it's a clarification of it. It still follows the same concepts, only the tools are made closer to read like you're actually specifying behavior instead of invalidating state with asserts. HTH! -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
"Dean Michael Berris" <mikhailberis@gmail.com> writes:
Hi Dave!
On 9/14/06, David Abrahams <dave@boost-consulting.com> wrote:
Watching the video about 25% through, so far I don't get what he's talking about or why BDD is different from what I do anyway or how it can benefit me.
It's really just a "clarification" of Test Driven Development. The gist is as follows:
* Instead of emphasizing on "Tests", you emphasize "Specification".
* The assert_* line of methods leans on the "testing" and "invalidation" of results and values.
Yeah, I heard him say that, but didn't buy that line at all. An ASSERT says: here's what I'm saying the behavior/result is. That's specification.
The language used is also not very clear when using it to specify behaviour.
* Specifications are made more readable. They have an implementation in Ruby called `RSpec' which uses a more readable framework than `assert_something(value_tested, expected_value)' -- you can look at http://rspec.rubyforge.org/ for more information on that.
Yeah, OK, so there's a DSL... not a very convincing one either, especially in light of the use of "should"
It's not different from TDD, but it's a clarification of it.
Somehow it was much less clear to me, because it was sold as some kind of revolution.
It still follows the same concepts, only the tools are made closer to read like you're actually specifying behavior instead of invalidating state with asserts.
You mean validating, don't you? And the distinction between state and behavior is extremely weak, at least as presented so far. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Yeah, OK, so there's a DSL... not a very convincing one either, especially in light of the use of "should"
It's not different from TDD, but it's a clarification of it.
Somehow it was much less clear to me, because it was sold as some kind of revolution.
A revolution in many small steps maybe, but I agree its not a quantum shift.
And the distinction between state and behavior is extremely weak, at least as presented so far.
One of the key ideas behind the BDD is that its trying to work around the image that the word 'test' has out in the world of programming at large. In a technical sense it isn't really all that different. However when you introduce the idea of customers writing the specification along with the developers you need a common language between the two, and thats where the DSL bit comes in. As an example I was at the Google Test Automation conference last week and there was an interesting presentation where once the 'punctuation' characters were removed (changed colour to white in the IDE) the tests read in English sentences that a business analyst would have been able to write. Admittedly if your in the business of writing frameworks where your customer is a developer this has less of a win. Its not really any different to some of the clever language/syntax hacks found in the Boost libraries. I'll take any productivity gain I can get, especially if its near zero cost :-) Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
Kevin Wheatley wrote:
As an example I was at the Google Test Automation conference last week and there was an interesting presentation where once the 'punctuation' characters were removed (changed colour to white in the IDE) the tests read in English sentences that a business analyst would have been able to write.
I gave up on the customer drive code ideas of COBOL long ago. code programming languages and program design languages address different domains. IMO it does a disservice to each try and mix them. You'll be better off if the business analyst writes those English sentences in a word processor as part of a design document. -- -- 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
Rene Rivera wrote:
I gave up on the customer drive code ideas of COBOL long ago. code programming languages and program design languages address different domains. IMO it does a disservice to each try and mix them.
Sure thats why people are using custom DSLs rather than the native language as is.
You'll be better off if the business analyst writes those English sentences in a word processor as part of a design document.
Indeed, especially if you can then run it through Fit/FitNess/FitLibrary/etc. The key being that they can be automatically run as acceptance tests, and directly expressable by the BA. 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. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
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
On 9/14/06, Rene Rivera <grafikrobot@gmail.com> wrote:
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.
</lurk> I've been keeping up with the discussion and I just need to speak up that yes, we should never get requirements like "make it look ghostly". Unfortunately, I can tell you from experience that sometimes managers are idiots and sometimes requests like this do come down the pipe. Furthermore, sometimes you're lucky to even get written requirements or specifications. Usually for me, especially around trade show time, requirements are delivered in conversation and management expects us to follow through with them. Anyways, sorry for the entirely off-topic post. I'll go back to lurking now. <lurk> Jeremy
Hi Rene! On 9/14/06, Rene Rivera <grafikrobot@gmail.com> wrote:
To take some of Dean's examples:
[snipped my examples]
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 ); ====
This is also similar to: int my_value = 0; assert(10 == my_value); assert( 9 != my_value); char * my_pointer = NULL; assert( NULL == my_pointer ); assert( NULL != my_pointer ); Which is precisely what BDD wants to get away from.
Hence why I don't see the point of BDD when I'd rather have a contract definition framework.
What a potential for having a BDD framework in place, is that you can have your system level tests (or acceptance tests) written out in english (in a text file) and generate your acceptance tests from that document. In your text file you'd probably see: Protocol Definition client sends "GET /index.html" to the server; server response is a string server response should equal "HTTP/1.1\r\n" And then you can come up with a pretty trivial tool (perhaps with Spirit or maybe Boost.Build) to generate something like the following: void protocol_definition { std::string server_response = client.sends("GET /index.html", server); // ignored to the value(server_response).should.equal("HTTP/1.1\r\n"); }; Then that allows you to re-write your acceptance tests according to the requirements, and be able to programmatically generate a program from that document format. Think of it as metaprogramming, but this time not just with templates and preprocessor directives. ;) That's just one of the potentials. Another is having to be able to communicate to other programmers a document derived from code, using almost the same process as outlined above. Of course, there is also the "it reads better" or "it reads naturally to me" factor, which is I think is one of the key things to remember when designing readable interfaces. :-) -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
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 |
Hi Kevin (and everyone else)! Attached are `spec.hpp' which implements the inital supported BDD terms (equal, not_equal, between(...)and(...) ). On 9/15/06, Kevin Wheatley <hxpro@cinesite.co.uk> wrote:
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.
I've been thinking about it, but unless I find a (better) way to be able to offer different specifications based on different subjects: there's value(...), object(...), pointer(...) then "should" will remain. (Please see attached files) Unless the following is possible: template <typename _T> struct value { explicit value(const _T & value) : _value(value) { }; const _T & value; // ... implement equals(), does_not_equal(), etc. etc. }; And be able to use `value' in the following use case: int i = 0; value(i).equals(0); And leverage automatic type deduction for type parameters (which I'm not sure is even possible)... I'm sticking with "should" for the meantime. :D
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.
I've attached the initial explorations (one header, and a test implementation). Comments and insights will be most appreciated. :)
[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.
Very interesting indeed. I would think BDD will be very useful in these situations, especially for the developers and even non-technical customers (who feel comfortable with english anyway). -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
Sorry, but I'm going to be rather uncharacteristically apolitically frank... Dean Michael Berris wrote:
Hi Kevin (and everyone else)!
Attached are `spec.hpp' which implements the inital supported BDD terms (equal, not_equal, between(...)and(...) ).
I've attached the initial explorations (one header, and a test implementation). Comments and insights will be most appreciated. :)
Yea... Looks as bad as I feared.
[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.
Very interesting indeed. I would think BDD will be very useful in these situations, especially for the developers and even non-technical customers (who feel comfortable with english anyway).
It's a very sad day when people can again think that customers can program. After 25 years of programming this seems to be a recurring false pattern. Having done a stint in knowledge based reasoning AI development I can tell you that there's a very good reason for the term "expert". And for those not familiar with some of the AI aspects in this, unless you are willing to make non-programmers write in Esperanto, you'll be faced with natural language parsing nightmares. -- -- 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
Hi Rene, On 9/15/06, Rene Rivera <grafikrobot@gmail.com> wrote:
Sorry, but I'm going to be rather uncharacteristically apolitically frank...
It's alright. :-)
Dean Michael Berris wrote:
I've attached the initial explorations (one header, and a test implementation). Comments and insights will be most appreciated. :)
Yea... Looks as bad as I feared.
Unfortunately, the implementation might need some work (aesthetically, or even code-wise). However, if the judgement is about the "value(...).should.equal(...)", then I'd like to think it might be a matter of preference. :-D Maybe it might need getting used to... :-) Staring at a whole slew of ASSERT_EQUAL or similar "un-englishlike" constructs along with the C++ constructs gets tiring at times -- much like beer, it's an acquired taste and it gets boring at times. After all, BDD is an alternative or a "language shift" to the traditional TDD approach of "Unit Testing".
[OT bit follows]
Very interesting indeed. I would think BDD will be very useful in these situations, especially for the developers and even non-technical customers (who feel comfortable with english anyway).
It's a very sad day when people can again think that customers can program. After 25 years of programming this seems to be a recurring false pattern. Having done a stint in knowledge based reasoning AI development I can tell you that there's a very good reason for the term "expert". And for those not familiar with some of the AI aspects in this, unless you are willing to make non-programmers write in Esperanto, you'll be faced with natural language parsing nightmares.
Yeah... But using language that's closer to "natural language" or in this case, English, makes the code/specification readable IMO. If not for the possibility of programmatically generating programmatic specifications (specification metaprogramming?) to even a considerably readable implementation in C++, BDD is Yet Another Testing And Software Engineering Paradigm. :-) -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
Dean Michael Berris wrote:
Hi Rene,
On 9/15/06, Rene Rivera <grafikrobot@gmail.com> wrote:
Sorry, but I'm going to be rather uncharacteristically apolitically frank...
It's alright. :-)
I thought it was going to be my last post... But these things have a way a barreling out of of control ;-)
Yea... Looks as bad as I feared.
Unfortunately, the implementation might need some work (aesthetically, or even code-wise).
Didn't look at it. I think the utility and hence design of the user interface is the item in question.
However, if the judgement is about the "value(...).should.equal(...)", then I'd like to think it might be a matter of preference. :-D
I'm going to disagree with a perspective sensitive simulation... [I put my programmer hat on being told by a manager that I need to understand and possibly write these things.] It looks like some English words trying to define a logical expression. How unnatural, and prone to errors. I'd rather write those as real expressions. [I put my customer hat on being told by the manager of a company I hired that this is what programmers need to write the software I'm paying for. And not only that I'm bound to do it because it's in the contract.] Hm, looks like English, this should be easy. Wait, what are all those periods. I only put periods at the end of sentences. I'll just write them the correct way. I talk to the manager, hand her the specs. Later she gets back to me that there are problems with the specs and the programmers can't use them. What do you mean they can't use them, it's perfectly valid English descriptions. What am I paying you for? Make the programmers read my specs. [I put on my manager hat (note, I can do all these hats because I have been all those, sometimes two of those at once)] OK, we'll use the specs. I go and talk to the programmers... These are the only specs we are getting so you must use them. What can we do? [Back to programmer] Well we can parse and translate them into our internal testing specs. That will take 3 months to write a barely tested NLP and KBR that we can use to translate. Or we can write a cheesy regex parser that we'll have to tweek until it works. That might take a month. Or we can have one of our junior programmers read the specs and write corresponding test code, and abandon the whole automated customer spec system. That will take a few days. [Back to manager] OK, fine, get the junior programmer working on it ASAP. [Back to programmer] Hey junior programmer... Translate these into code we can understand. You have 2 days. ...Junior programmer goes and works to death for 24 of the next 48 hours. But only gets paid for 16 of those as a salaried employee. :-(
Maybe it might need getting used to... :-)
The human brain has this stubborn ability to directly map things it gets used to, to the singular generic case. Hence you'll end up writing natural English in no time flat.
Staring at a whole slew of ASSERT_EQUAL or similar "un-englishlike" constructs along with the C++ constructs gets tiring at times -- much like beer, it's an acquired taste and it gets boring at times. After all, BDD is an alternative or a "language shift" to the traditional TDD approach of "Unit Testing".
Sure, using the same tool over and over again can get really boring. But it's invariably a bad idea, no matter how novel it might seem at the time, to use a pencil to hammer in a nine inch nail.
Yeah... But using language that's closer to "natural language" or in this case, English, makes the code/specification readable IMO.
But you at minimum understand C++. Try the example you posted and hand it over to a nearby secretary, admin assistant, mail clerk, artist, marketing vp, etc. and ask them to explain it.
If not for the possibility of programmatically generating programmatic specifications (specification metaprogramming?) to even a considerably readable implementation in C++
One of the hallmarks of knowledge based reasoning AI system is the separation of expert domains with appropriate translation and interpretation between the human knowledge and its programmatic equivalent. At each of those rifts of expertise there is either a very complex knowledge understanding system that does, if you are lucky, 25% of the job of going from domain to program. Or; You have a highly qualified human multi-domain translation expert that will do 100% of the translation job with a magnitude better efficiency for 1% of the cost of the programmatic translator.
, BDD is Yet Another Testing And Software Engineering Paradigm.
I think you mean "Testing And Software Engineering Method" ;-) Note, if it wasn't clear enough. My point is that you can achieve much better results with human documentation for considerably lower investment than what you would be able to achieve with such COBOL like program spec languages. -- -- 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
Rene Rivera wrote:
It's a very sad day when people can again think that customers can program. After 25 years of programming this seems to be a recurring false pattern. Having done a stint in knowledge based reasoning AI development I can tell you that there's a very good reason for the term "expert". And for those not familiar with some of the AI aspects in this, unless you are willing to make non-programmers write in Esperanto, you'll be faced with natural language parsing nightmares.
This is probably off-topic, but I've struggled with this question, and would like to hear more on this. If it should be in a different list, please help me to move the discussion there. It's not so much that I would ever expect laypersons to be able to program. But I do expect the code to be written such that the layperson can get the gist, if not every detail, of what it is to be doing. I have been recently working with the notion that as much as possible (and that's quite a bit), C++ objects, etc., should be in the terms of the problem domain: nothing too controversial there. Even if I were working procedurally in C rather than in OO with C++, I would want my breakdown to make sense with regard to the domain it is responding to. Further, and this is potentially the rub, the implementation should also be in those terms. If we're talking about simpler programs such as examples in undergraduate CS courses, this is fairly obvious, but it's real value is in the more complex code, such as in commercial production. So often code ends up overly complex and rife with potential error simply because it couldn't be read. If you follow the principle that a layperson should be able to follow it, then you've probably thought enough about how you'd explain it that you've done a better job of organizing the code. I've seen code written for academic purposes and much of it requires far more from the reader than should ever be necessary. Even with C++ templates where the syntax can be very arcane, one might have to help read past that and I certainly would agree that a detailed, bit by bit analysis of the consequences of its code construction would likely be going too far. But again, a reader should be able to follow the general points of the algorithm and use this as a way to reconcile specification and expectation with actual code design. In short, the closer the code is written in terms of the specification (whether formally or informally developed), the less likely the designer will miss the mark. The exceptions I allow to this principle generally occur in performance-critical code. Finally, I'm not suggesting that code be written such that it matches the original explanation given by a layperson customer; frequently they haven't done sufficient analysis to recognize better design possibilities. However, once a design is developed, the customer should be able to follow what it is as kind of an application of the Feynman freshman explanation principle (experts are only experts if they can explain the subject to a layperson). So if you have a more rigourous way of determining where the line should be drawn or if my premise is not supportable, I would be all ears (or eyes as the case is here). Kind regards, Richard Newman richard@cdres.com
Richard Newman wrote:
Rene Rivera wrote:
It's a very sad day when people can again think that customers can program. After 25 years of programming this seems to be a recurring false pattern. Having done a stint in knowledge based reasoning AI development I can tell you that there's a very good reason for the term "expert". And for those not familiar with some of the AI aspects in this, unless you are willing to make non-programmers write in Esperanto, you'll be faced with natural language parsing nightmares.
This is probably off-topic, but I've struggled with this question, and would like to hear more on this. If it should be in a different list, please help me to move the discussion there.
It's not so much that I would ever expect laypersons to be able to program. But I do expect the code to be written such that the layperson can get the gist, if not every detail, of what it is to be doing.
I have been recently working with the notion that as much as possible (and that's quite a bit), C++ objects, etc., should be in the terms of the problem domain: nothing too controversial there. Even if I were working procedurally in C rather than in OO with C++, I would want my breakdown to make sense with regard to the domain it is responding to.
Further, and this is potentially the rub, the implementation should also be in those terms. If we're talking about simpler programs such as examples in undergraduate CS courses, this is fairly obvious, but it's real value is in the more complex code, such as in commercial production. So often code ends up overly complex and rife with potential error simply because it couldn't be read. If you follow the principle that a layperson should be able to follow it, then you've probably thought enough about how you'd explain it that you've done a better job of organizing the code. I've seen code written for academic purposes and much of it requires far more from the reader than should ever be necessary.
Even with C++ templates where the syntax can be very arcane, one might have to help read past that and I certainly would agree that a detailed, bit by bit analysis of the consequences of its code construction would likely be going too far. But again, a reader should be able to follow the general points of the algorithm and use this as a way to reconcile specification and expectation with actual code design. In short, the closer the code is written in terms of the specification (whether formally or informally developed), the less likely the designer will miss the mark. The exceptions I allow to this principle generally occur in performance-critical code.
Finally, I'm not suggesting that code be written such that it matches the original explanation given by a layperson customer; frequently they haven't done sufficient analysis to recognize better design possibilities. However, once a design is developed, the customer should be able to follow what it is as kind of an application of the Feynman freshman explanation principle (experts are only experts if they can explain the subject to a layperson).
So if you have a more rigourous way of determining where the line should be drawn or if my premise is not supportable, I would be all ears (or eyes as the case is here).
But why would a layperson have to read pseudo-english embedded in arcane C++ when she can read the documentation? IMO, (sorry Dean) all this hoopla is just an elaborate excuse not to write proper detailed documentation. IMO, programs that end up overly complex and rife with potential error stems from the lack of documentation and design discipline. Code goes haywire and get into a tangled mess, and hence become unreadable in the process. It does not start from unreadable code, it starts from lack of, inadequate, or improper documentation. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
But why would a layperson have to read pseudo-english embedded in arcane C++ when she can read the documentation? IMO, (sorry Dean) all this hoopla is just an elaborate excuse not to write proper detailed documentation. IMO, programs that end up overly complex and rife with potential error stems from the lack of documentation and design discipline. Code goes haywire and get into a tangled mess, and hence become unreadable in the process. It does not start from unreadable code, it starts from lack of, inadequate, or improper documentation.
Two reasons come to mind: (1) often writing "proper detailed documentation" isn't appropriate, and (2) translation error. Writing separate documentation isn't always appropriate or desired. For instance, in an XP scenario, you only write that documentation that will be immediately useful: users' guides and the like; it would be an undesired weight on the development effort to write internal code construction documentation. You count on the code construction and the unit tests to directly communicate the notions to follow on programmers. Further, writing documentation of the algorithms at a detailed enough level to understand what the details of the design was may have a cost at least as high as writing the code itself. At the very least, the code itself should communicate to the next reader, be it layperson or programmer, what the design was; otherwise, we could go back to 4 letter variable names. Since you go that far, why not have the discipline to write readable code, readable at least at some level by the layperson? Why write it twice: once in code and once in natural language? Perhaps I've not correctly interpreted what you mean by "proper detailed documentation." IMHO, proper detailed documentation is simply readable code. Second, every time you translate between the spec and the code, you introduce the possibility of translation error. It's bad enough when under classic lifecycles, you might translate from spec to analysis models to design documents to code to test scripts, then you add documentation to describe what you did. It may not be reasonably as Rene pointed out to do this directly from spec to code, but from reconciling from code to spec ought to be possible. At some degree, having the code clearly reflect the algorithms involved, such that a layperson can assess what product does, allows these translation layers to be reduced. Finally, please note that I would not advocate writing code such that C++ operators and the like are rewritten into pseudo-English (or whichever). For instance, the tertiary operation is what it is and this I intend to solve by explaining to a lay person what it means rather than going through goofy gyrations just to make it look like natural language. Most people would get the gist that "==" means whether something is equal to something else. However, writing some dense formula that depends on operation precedence is not as readable as breaking a formula down with clear variables or using explicit parentheses to help a reader follow the logic and reason for formula. Regards, Richard
Richard Newman wrote:
Joel de Guzman wrote:
But why would a layperson have to read pseudo-english embedded in arcane C++ when she can read the documentation? IMO, (sorry Dean) all this hoopla is just an elaborate excuse not to write proper detailed documentation. IMO, programs that end up overly complex and rife with potential error stems from the lack of documentation and design discipline. Code goes haywire and get into a tangled mess, and hence become unreadable in the process. It does not start from unreadable code, it starts from lack of, inadequate, or improper documentation.
Two reasons come to mind: (1) often writing "proper detailed documentation" isn't appropriate, and (2) translation error.
Writing separate documentation isn't always appropriate or desired. For instance, in an XP scenario, you only write that documentation that will be immediately useful: users' guides and the like; it would be an undesired weight on the development effort to write internal code construction documentation. You count on the code construction and the unit tests to directly communicate the notions to follow on programmers.
Even with XP, there's planning and design. I sure hope that would be documented before and after coding (when there are changes from the specs). The plan and design is more important to the layperson. Without it, it's simply hacking in the guise of XP. I wouldn't trust anyone to build my house without design and a plan detailed in documentation.
Further, writing documentation of the algorithms at a detailed enough level to understand what the details of the design was may have a cost at least as high as writing the code itself. At the very least, the code itself should communicate to the next reader, be it layperson or programmer, what the design was; otherwise, we could go back to 4 letter variable names. Since you go that far, why not have the discipline to write readable code, readable at least at some level by the layperson?
Oh my. Do you expect the layperson to read your code? Consider a code snippet (the humble for_each) lifted from STL (from g++): /** * @brief Apply a function to every element of a sequence. * @param first An input iterator. * @param last An input iterator. * @param f A unary function object. * @return @p f. * * Applies the function object @p f to each element in the range * @p [first,last). @p f must not modify the order of the sequence. * If @p f has a return value it is ignored. */ template<typename _InputIterator, typename _Function> _Function for_each(_InputIterator __first, _InputIterator __last, _Function __f) { // concept requirements __glibcxx_function_requires(_InputIteratorConcept<_InputIterator>) __glibcxx_requires_valid_range(__first, __last); for ( ; __first != __last; ++__first) __f(*__first); return __f; } I would be thankful for the documentation written prior at the top. There's no such thing as self documenting code. I don't think BDD will even help in documenting the intent of the algorithm. Give it a shot and see if you can capture the intent: "Applies the function object f to each element in the range[first,last). f must not modify the order of the sequence. If f has a return value it is ignored.".
Why write it twice: once in code and once in natural language? Perhaps I've not correctly interpreted what you mean by "proper detailed documentation." IMHO, proper detailed documentation is simply readable code.
Or maybe I've not correctly interpreted what you mean by "documentation is simply readable code". 1) Is the code above equally readable without the documentation at the top? 2) How would you capture the behavior of the algorithm with BDD?
Second, every time you translate between the spec and the code, you introduce the possibility of translation error. It's bad enough when under classic lifecycles, you might translate from spec to analysis models to design documents to code to test scripts, then you add documentation to describe what you did. It may not be reasonably as Rene pointed out to do this directly from spec to code, but from reconciling from code to spec ought to be possible. At some degree, having the code clearly reflect the algorithms involved, such that a layperson can assess what product does, allows these translation layers to be reduced.
The question is how BDD can help write code that clearly reflects the algorithms involved. Try the simple for_each, see if you can convince me. Then try a more elaborate algorithm, say, quicksort. See if you can capture the essence of the algorithm in BDD. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Hi Joel! On 9/16/06, Joel de Guzman <joel@boost-consulting.com> wrote:
The question is how BDD can help write code that clearly reflects the algorithms involved. Try the simple for_each, see if you can convince me. Then try a more elaborate algorithm, say, quicksort. See if you can capture the essence of the algorithm in BDD.
I think there's a blurring between the use of documentation and specification here. Let me try to clarify a few things as to what BDD wants to be able to achieve: * Write Specification Suites for validating program behaviour :: In lieu of calling these specification suites "test suites". * Allow for writing programmatic specifications for systems, subsystems, components, and "units" :: in liew of calling them system level tests, integration tests, and unit tests BDD does not aim to remove external documentation, but it does aim to make the specification process programmatically consistent with natural language. Instead of "Unit Testing" you have "Behavior Specification". Contrasting `ASSERT_EQUAL(_expected, _value)' with `value(_value).should.equal(_expected)'. It's really just that simple. ;-) -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
Dean Michael Berris wrote:
Hi Joel!
On 9/16/06, Joel de Guzman <joel@boost-consulting.com> wrote:
The question is how BDD can help write code that clearly reflects the algorithms involved. Try the simple for_each, see if you can convince me. Then try a more elaborate algorithm, say, quicksort. See if you can capture the essence of the algorithm in BDD.
I think there's a blurring between the use of documentation and specification here. Let me try to clarify a few things as to what BDD wants to be able to achieve:
* Write Specification Suites for validating program behaviour :: In lieu of calling these specification suites "test suites".
* Allow for writing programmatic specifications for systems, subsystems, components, and "units" :: in liew of calling them system level tests, integration tests, and unit tests
BDD does not aim to remove external documentation, but it does aim to make the specification process programmatically consistent with natural language.
Instead of "Unit Testing" you have "Behavior Specification". Contrasting `ASSERT_EQUAL(_expected, _value)' with `value(_value).should.equal(_expected)'. It's really just that simple. ;-)
Fair enough. Perhaps I was just taken aback by the hype. I find it alarming whenever I read things like "the next big thing", a "revolution", etc. Reminds me a lot about Java. (sorry, can't resist). Anyway, I should assert (pardon the pun ;) ) that behavior specification in code (as a DSEL?) is an illusion. People would tend to believe that with it, you can specify a program behavior and get away with no documentation. Proof in point: Richard Newman's post (unless I misunderstood him). That makes me worry. Regrards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Hi Joel! On 9/17/06, Joel de Guzman <joel@boost-consulting.com> wrote:
Fair enough. Perhaps I was just taken aback by the hype. I find it alarming whenever I read things like "the next big thing", a "revolution", etc. Reminds me a lot about Java. (sorry, can't resist).
Yeah... I kinda glossed over that, and was just amazed at the "readable" sample that the guy in the video was showing (in the ruby examples). :-) I never really took it as a "revolution" or "next big thing". :-D However I agree about the Java comment. :-D
Anyway, I should assert (pardon the pun ;) ) that behavior specification in code (as a DSEL?) is an illusion. People would tend to believe that with it, you can specify a program behavior and get away with no documentation. Proof in point: Richard Newman's post (unless I misunderstood him). That makes me worry.
It's a bit of a stretch, but I think the BDD interface to specification as opposed to the Assert methods for TDD are mere alternatives to each other. Because: ASSERT_EQUAL(a, 10) Is pretty much tantamount and equivalent to: value(a).should.equal(10); It's a case of "Tomaytoe" "Tomahtoe" :-D -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
Dean Michael Berris wrote:
On 9/17/06, Joel de Guzman <joel@boost-consulting.com> wrote:
Anyway, I should assert (pardon the pun ;) ) that behavior specification in code (as a DSEL?) is an illusion. People would tend to believe that with it, you can specify a program behavior and get away with no documentation. Proof in point: Richard Newman's post (unless I misunderstood him). That makes me worry.
It's a bit of a stretch, but I think the BDD interface to specification as opposed to the Assert methods for TDD are mere alternatives to each other.
Alternatives just tend to confuse things more than help.
Because:
ASSERT_EQUAL(a, 10)
Is pretty much tantamount and equivalent to:
value(a).should.equal(10);
It's a case of "Tomaytoe" "Tomahtoe" :-D
True. But neither of those is more readable to the likely person writing the specs/tests than: test( a == 10 ); Yes I keep changing the function name, I used "ensure" and someone replied that it was the same as "assert". And yes, that's my point. It's a mechanism that programmers are already familiar with, and comes naturally to them. So why rewrite it into a less capable form? I have another simple question; Does Ruby have the equivalent of assert? -- -- 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
Even with XP, there's planning and design. I sure hope that would be documented before and after coding (when there are changes from the specs). The plan and design is more important to the layperson. Without it, it's simply hacking in the guise of XP. I wouldn't trust anyone to build my house without design and a plan detailed in documentation. Agreed. My earlier comments were more addressed to the notion of documenting only for the sake of documenting. Most useful design
Oh my. Do you expect the layperson to read your code? Consider a code snippet (the humble for_each) lifted from STL (from g++):
/** * @brief Apply a function to every element of a sequence. * @param first An input iterator. * @param last An input iterator. * @param f A unary function object. * @return @p f. * * Applies the function object @p f to each element in the range * @p [first,last). @p f must not modify the order of the sequence. * If @p f has a return value it is ignored. */ template<typename _InputIterator, typename _Function> _Function for_each(_InputIterator __first, _InputIterator __last, _Function __f) { // concept requirements __glibcxx_function_requires(_InputIteratorConcept<_InputIterator>) __glibcxx_requires_valid_range(__first, __last); for ( ; __first != __last; ++__first) __f(*__first); return __f; }
I would be thankful for the documentation written prior at the top. There's no such thing as self documenting code. I don't think BDD will even help in documenting the intent of the algorithm.
Give it a shot and see if you can capture the intent: "Applies the function object f to each element in the range[first,last). f must not modify the order of the sequence. If f has a return value it is ignored.". But you did do what I asked for! I never said that you can't have comments, though one's reliance on them should be as minimal as
Sorry, I'm behind; I didn't follow the thread over the weekend. Joel de Guzman wrote: processes result in useful documentation as a result of the design approach and are not written after the fact to fulfill some kind of procedures standard. The best approaches produces documentation almost as a necessary side effect. I generally ask individuals to write out their proposals and present them to one another and others to a level of detail necessary to convey to the involved stakeholders that each understands the other. Is it exhaustive in detail? No, not at all. Does it provide a framework and criteria for measuring successful results? Yes. They iterate and refactor on that just as they would the code. Such writing is their tool and platform for working out their approach and reaching agreement. As a result we end up documentation without having to do it after the fact or add more weight to the process. It may not be in a standard format or prove how every detail will work with certainty, but it does provide the essential 80% of what we do need to reasonably approach the problem. possible. In this example, you have variable names that convey their role (except "_f" might have been better as "_function") and I probably would have used braces and indentation for the inner single line for-loop. Style points to be sure, but ones that might allow a layperson to more easily grasp the code's intent. I think my point is one that we probably take as a best practice anyway: you do in the code what must be done so that next reader can understand what you were trying to do and why you did it. We often have to contend with other programmers, let alone laypersons, who would struggle to read the above code without documentation. Why not accept that and have the discipline to make it readable to a somewhat broader audience. Even so, I could reasonably get across the gist that this loops through everything passed to it and applies a given function. I'm not suggesting that we dumb code down and avoid language constructs, just that we don't make its meaning more obscure than necessary. I'm not suggesting that a layperson will follow the detailed nuance of it. But client code using the above code will now likely use a more readable for_each loop and the semantics are somewhat more clear to non-C++ readers. As I said in my earlier post, I'm not expecting 100% solvency here, just that we consider the code, with its test cases, a key part of the final documentation. Any documentation that attempts to restate the code after the fact will likely introduce translation errors and increase maintenance. Indeed, even the comments can suffer this, but at least they're inline where they can be considered at the same time. If we take care to have the code, especially at higher levels, clearly depict the logic for a wider audience, we can better assure that we're consistent with specs. Unfortunately, programmers are often too clever, writing something that never matches the problem statement in its construction and that has dubious performance improvements. Yes, it might be for that day, for that set of tests, they might have had results that matches results expected in the specification, but if it doesn't follow the same approach, how can we reasonably validate its side effects and bounds of performance? Instead you have a scenario where the sponsor asks did you do item A and the programmer nods yes and points at a couple of tests but really they did B or some variant of A that if the sponsor could read it would realize some essential point of departure that hadn't been thought of to measure in the tests.
Or maybe I've not correctly interpreted what you mean by "documentation is simply readable code". 1) Is the code above equally readable without the documentation at the top? 2) How would you capture the behavior of the algorithm with BDD?
As I said in my first post, I'm struggling my articulation of this notion and avoiding some realm of Colbert-ian truthiness given that I don't have any bright lines. But it seems to be a Good Thing if code can reflect the problem statement as close as possible and to be written in a way that reduces how arcane it is so that stakeholders can participate in its direct review.
The question is how BDD can help write code that clearly reflects the algorithms involved. Try the simple for_each, see if you can convince me. Then try a more elaborate algorithm, say, quicksort. See if you can capture the essence of the algorithm in BDD. I wasn't acting as a proponent or opponent of BDD as I'm not familiar with it, but would too invite those BDD proponents to respond.
My first post was in response to Rene Rivera's comment with regard to the dark days of laypersons coding. I agree with that sentiment (something about Shakespeare and monkeys comes to mind), but think that there is a middle road that would improve our practice. If I've distracted the thread, I apologize, but it seemed a good opportunity to let others beat on this straw-man I'm wrestling with. I very much appreciate your responding to my posts. Regards, Richard
Richard Newman <richard@cdres.com> writes: <snip XP philosophy>
IMHO, proper detailed documentation is simply readable code.
This is part of the reason I have such a hard time with XP. The first problem is that the author of a piece of code almost invariably overestimates its readability. It's common that even the original author can't understand what he was doing after 6 months go by. The second problem is that you can't determine the correctness of code by looking at it without a specification. The redundancy provided by documentation is important.
At some degree, having the code clearly reflect the algorithms involved, such that a layperson can assess what product does, allows these translation layers to be reduced.
You're seriously suggesting that the layperson can read the code and assess what the product does?
Finally, please note that I would not advocate writing code such that C++ operators and the like are rewritten into pseudo-English (or whichever).
For instance, the tertiary operation
ternary [ie. "?:"] operator? -- Dave Abrahams Boost Consulting www.boost-consulting.com
Richard Newman <richard@cdres.com> writes:
IMHO, proper detailed documentation is simply readable code.
This is part of the reason I have such a hard time with XP.
The first problem is that the author of a piece of code almost invariably overestimates its readability. It's common that even the original author can't understand what he was doing after 6 months go by. I agree. All the more reason to consider writing it with the layperson in mind as part of the audience. One will take more care to avoid obscuring detail. Even when I didn't follow XP, I still thought this
David Abrahams wrote: point was a good idea for the reason you just gave.
The second problem is that you can't determine the correctness of code by looking at it without a specification. The redundancy provided by documentation is important.
I never suggested that one doesn't write specs. At the very least, TDD might be a minimal substitute for specs if you had nothing else. My point was more in response to not having to repeat the code in natural language documentation when we could certainly avoid writing obscure code in the first place.
At some degree, having the code clearly reflect the algorithms involved, such that a layperson can assess what product does, allows these translation layers to be reduced.
You're seriously suggesting that the layperson can read the code and assess what the product does?
As I said before, only to a degree. I don't see why this has to be viewed as a dichotomy rather than a continuum. We can write code that is less obscure, that where at all possible and certainly at higher levels, can reveal algorithms that can be followed by laypersons. I'm not suggesting we expect laypersons to know the distinction between passing parameters by reference or by value, but if the code lays out its approach in reasonable objects and method construction for the domain space, laypersons likely can follow the gist of what is being done and evaluate how well the code reflects intent. The effort to do so would acknowledge the value of the ideal even if it can't always be achieved in practice. Write the code to what it must do, but do so in a way that allows it to be read by the widest audience possible.
For instance, the tertiary operation
ternary [ie. "?:"] operator?
Yes, sorry. I sometimes stumble when I pronounce aluminum too. :) Regards, Richard Newman
Hi Joel! On 9/15/06, Joel de Guzman <joel@boost-consulting.com> wrote:
But why would a layperson have to read pseudo-english embedded in arcane C++ when she can read the documentation? IMO, (sorry Dean) all this hoopla is just an elaborate excuse not to write proper detailed documentation.
Yes, having someone else read pseud-english in C++ is a bit too much to ask. But for the programmers' sake, reading something that's meant to be a specification and use it as such in code might be helpful. At least I seem to think it is. ;-)
IMO, programs that end up overly complex and rife with potential error stems from the lack of documentation and design discipline. Code goes haywire and get into a tangled mess, and hence become unreadable in the process. It does not start from unreadable code, it starts from lack of, inadequate, or improper documentation.
Indeed. But documentation aside, the same reason why we have unit tests is to test whether a system is within specification. This approach is just yet another way of specifing expected behavior, using a closer to english language. At least, this is the aim of the spec library anyway. :-) -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
Dean Michael Berris wrote:
I've attached the initial explorations (one header, and a test implementation). Comments and insights will be most appreciated. :)
My take would be that whilst the syntax for expressing the specifications is OK (possibly needs a little more thought) I didn't like the idea of exceptions being thrown if the spec is broken. I'd much prefer a interface, that would better integrate with Boost Test for its error reporting, and it would avoid all that duplication in try/catch blocks and make it more readable (the whole point :-) Personally I don't mind getting lots of errors, in the non perfect test suites I end up writing, multiple errors can help 'factor out' the likely bugs I've written. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
Hi Kevin! On 9/15/06, Kevin Wheatley <hxpro@cinesite.co.uk> wrote:
Dean Michael Berris wrote:
I've attached the initial explorations (one header, and a test implementation). Comments and insights will be most appreciated. :)
My take would be that whilst the syntax for expressing the specifications is OK (possibly needs a little more thought) I didn't like the idea of exceptions being thrown if the spec is broken.
Yeah... Now that I'm reading it again, I'm beginning to think about removing the exceptions part. It seemed like a good idea at first, but apparently the client code (the one in main(...) ) doesn't look too good with all the try {} catch (...) {} blocks.
I'd much prefer a interface, that would better integrate with Boost Test for its error reporting, and it would avoid all that duplication in try/catch blocks and make it more readable (the whole point :-)
This was the original idea (integrating with Boost.Test), but I ran into problems with Boost 1.33.1 and MSVC 8. So I tried to come up with something that's not yet tied with anything Boost related, and the output was what was attached to my other message. :-)
Personally I don't mind getting lots of errors, in the non perfect test suites I end up writing, multiple errors can help 'factor out' the likely bugs I've written.
Indeed. I understand completely. :-) -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
"Dean Michael Berris" <mikhailberis@gmail.com> writes:
I've been thinking about it, but unless I find a (better) way to be able to offer different specifications based on different subjects: there's value(...), object(...), pointer(...) then "should" will remain. (Please see attached files)
Even the guy giving that talk objects strongly to "should" but was overruled by his colleagues for reasons he couldn't justify. If you're gonna go this way, "must" (**) would be appropriate. (**) or, better, simply "is" if you really want to make it more like specification and less like testing. But of course, "is" makes it an assertion, which this BDD philosophy somehow considers anathema. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hi Dave! On 9/17/06, David Abrahams <dave@boost-consulting.com> wrote:
"Dean Michael Berris" <mikhailberis@gmail.com> writes:
I've been thinking about it, but unless I find a (better) way to be able to offer different specifications based on different subjects: there's value(...), object(...), pointer(...) then "should" will remain. (Please see attached files)
Even the guy giving that talk objects strongly to "should" but was overruled by his colleagues for reasons he couldn't justify. If you're gonna go this way, "must" (**) would be appropriate.
I think "must" can be a reference to the "should" instance in the spec<> created by value(...), object(...), pointer(...) or something(...) so that the same things that can be done with "should" are interchangeable with "must". value(a).should.equal(10); value(a).must.equal(10); // works the same as above :D
(**) or, better, simply "is" if you really want to make it more like specification and less like testing. But of course, "is" makes it an assertion, which this BDD philosophy somehow considers anathema.
Yeah, and "is" could very well be yet another alias/reference to the "should" object contained in the spec<> object. ;-) -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
Hi Dave! On 9/14/06, David Abrahams <dave@boost-consulting.com> wrote:
"Dean Michael Berris" <mikhailberis@gmail.com> writes:
It's really just a "clarification" of Test Driven Development. The gist is as follows:
* Instead of emphasizing on "Tests", you emphasize "Specification".
* The assert_* line of methods leans on the "testing" and "invalidation" of results and values.
Yeah, I heard him say that, but didn't buy that line at all. An ASSERT says: here's what I'm saying the behavior/result is. That's specification.
When you get used to ASSERT_SOMETHING(value, expected), you run into "testing mode" because that's what ASSERTs read like. There's nothing inherently wrong with specifying behaviour by asserting that a state be true (or not true) after a set of operations -- it just doesn't "read as well as" something like `value(value).should.equal(expected)'.
* Specifications are made more readable. They have an implementation in Ruby called `RSpec' which uses a more readable framework than `assert_something(value_tested, expected_value)' -- you can look at http://rspec.rubyforge.org/ for more information on that.
Yeah, OK, so there's a DSL... not a very convincing one either, especially in light of the use of "should"
The idea with the use of 'should' is mainly for readability in lieu of asserts. Additionally, you can even introduce something like "can" used in this context: type<my_type>::can::serialize; type<my_type>::can::index_<int>; type<my_type>::can::be_a_functor< int (int, int) >; type<my_type>::can::not_be_derived_from<parent_type>; For static behavioral specification/testing. So now you can generate your test suite that can read like: //... type<my_type>::can::serialize; my_type my_first_instance, my_next_instance; my_first_instance.set_value(1); //... deserialize ar >> my_next_instance; value(my_next_instance.get_value()).should.equal(1);
It's not different from TDD, but it's a clarification of it.
Somehow it was much less clear to me, because it was sold as some kind of revolution.
I don't think I also caught on to the "revolution", but I really liked how the code read like with "should" instead of "assert". :-)
It still follows the same concepts, only the tools are made closer to read like you're actually specifying behavior instead of invalidating state with asserts.
You mean validating, don't you?
Yes, I meant validating. :-)
And the distinction between state and behavior is extremely weak, at least as presented so far.
Indeed, but the idea of being able to specify with more readable (english) language allows you to think in specification mode, thus the distinction of state and bahvaior can be made egligible. [I don't think that last statement made a lot of sense, but I wrote it anyway... ;-) ] -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
"Dean Michael Berris" <mikhailberis@gmail.com> writes:
Hi Dave!
On 9/14/06, David Abrahams <dave@boost-consulting.com> wrote:
Watching the video about 25% through, so far I don't get what he's talking about or why BDD is different from what I do anyway or how it can benefit me.
It's really just a "clarification" of Test Driven Development. The gist is as follows:
J.B. Rainsberger sums it up: http://www.jbrains.ca/postings/read/38 Fundamentally, Behaviour-driven development is Test-driven development practiced correctly, though frameworks tend to have different naming conventions. As JB points out, the wording is key --- some people associate specific meanings with the word "test", which aren't what TDD is about, and using "behaviour specification" instead gets around that. I have experimented with various syntaxes in C++, such as CHECK(some_value, must_be > 2 and must_be < 42); CHECK(some_container, must_contain(3)); In the end, I've always come back to our trusty friend: ASSERT. ASSERT_GREATER_THAN(some_value,2); ASSERT_LESS_THAN(some_value,42); ASSERT_NOT_EQUALS(std::count(some_container.begin(),some_container.end(),3),0); Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
participants (9)
-
Anthony Williams -
David Abrahams -
Dean Michael Berris -
Jeremy Day -
Joel de Guzman -
Kevin Wheatley -
Maciej Sobczak -
Rene Rivera -
Richard Newman