It's been a month since I've posted here and I sense this Technology Blather feels more than a bit neglected (especially if it's found out how active I've been on the other two non-techie blogs I maintain). Frankly, I just haven't been feeling all that passionate about the world of technology lately - nothing has really floated my boat and gotten me fired up. I'm always interested in unique solutions to web-scale capacity and concurrency problems, and data integration sort of falls into that bin for me as well.
I've been piddling around with Erland and Scala around the house and checking out what folks are doing in the world of web and object caching for large-scale distributed systems. But nothing to write home (or, more specifically, to write here) about.
Gregor had an interesting post just a bit ago. Gregor doesn't post on his blog a whole lot, but when he does, it's always worth reading.
Ted Dziuba is entertaining as always and introduced Milo.com late last month.
Dan North talks about two of my favorite software development approaches (one pattern based and the other process based) and shows how they are in so many ways very much made for one another.
But none of this is new under the sun - all of it is great but nothing earth shattering. I'm hoping for good things come 2010 ...
Showing posts with label bdd. Show all posts
Showing posts with label bdd. Show all posts
Wednesday, December 9, 2009
Friday, October 9, 2009
Other Peoples Words (a lazy man's perspective)
Some really great tech articles this week that I'm digging on ...
- Closing the Gap Between Apps and Operations (this gap is one of my pet peeves)
- Cucumbered (I can never get enough of this framework - love it)
- Deploying to Production Every Week (and the discipline to be able to pull it off)
- Spring 3.0 RC 1 Overview (a good overview from one of Spring's two Dads)
- More Meta-Metrics (I love everything about this blog, but especially the attitude)
Monday, August 10, 2009
BDD != functional testing
Why did Behavior Driven Development morph into "functional testing", somehow separate from Test Driven Development? That was certainly not Dan North's intent when he devised BDD. Ironically, he came up with it as a response to people's misconception of TDD as being about testing. He thought that creating a 'new' way of doing things ("new" in the window dressing sense) with precise language would put the emphasis on behavior rather than testing. But behavior doesn't mean functional testing. You can test the behavior of a single method of a single class using BDD and that's as narrowly scoped, white-box, unit test as you can get. If you express it using the BDD ubiquitous language, it's BDD (whether through tooling, or a Domain Specific Language or simply using Given/When/Then naming conventions within your unit test suite).
Time off for good behavior
Dan North has a great talk on Behavior Driven Development (BDD) posted over on InfoQ. I love the genesis behind BDD: it started with Dan being frustrated over people thinking that Test Driven Development (TDD) was about tests.
TDD is really about a way of designing and developing with a consumer/client focused bent: you start by walking in the shoes of your customer, using the software you haven't built yet. The customer in the case of TDD might be you - maybe you'll be consuming the methods of the class you're about to develop in order to develop a higher level class. But that's just a matter of scope and doesn't change the fact that you need to develop from the perspective of the person that will be using that particular piece of software.
We call these prototypical consumption exercises "writing tests", but in Dan's mind that was looking at it the wrong way - it's really focused on the behavior of your software. Thus Behavior Driven Development.
BDD has since morphed into something more than just another way of looking at TDD, providing a textual grammar (a "Domain Specific Language", albeit a small one) for specifying "given these conditions, when I execute this action, then I should have these results". Given, When, Then. Pretty simple.
"Getting the words right", Dan North said. Words being so important and so often dismissed. Getting words wrong (or at least not agreeing on or thinking about the same things when you say something) might be the single biggest source of pain in our industry (indeed, in the world).
This is one of the many reasons why I'm a big proponent of another agile discipline, Domain Driven Design (DDD), is its idea of a Ubiquitous Language.
Anyway, "Given, When, Then". Sort of acceptance criteria-like - thus BDD is often labeled an 'acceptance' testing process. I personally think that boxes into something smaller than it deserves: I think it can be used for unit testing and functional testing and integration testing too.
The idea that you can execute textual user stories is pretty powerful. Done right, it implies no more (or at least minimal) separate "requirements documents" or "test plans" or the dreaded "traceability" documents that often accompany them. That's where the BDD tools come in. And there are a lot of them: RSpec, Cucumber (for Ruby) and JBehave (Java) are probably the most popular.
But it's not about the tools, be clear, but rather the people and their interactions - having more of the latter with the former. If you haven't, take a look: there is a wide world of sports beyond your father's unit testing.
There is also a rockin' talk on "pragmatic Scala" - two of my favorite things. Scala has everything I love: a strong sense of concurrency built into the language ('actors!'), static typing but with a brevity of syntax, a functional bent ('to iterate is human, to recurse divine'), runs on the Java Virtual Machine. Great stuff. Good for you. The details of the language around how you invoke methods and what symbols you can use to name them has resulted in a lot of Scala code that's hard to read, but the idea of Scala is absolutely wonderful. I'm only just thinking in terms of its pragmatic value, with visions of Perl-like obfuscation dancing in my head. But still, check it out.
TDD is really about a way of designing and developing with a consumer/client focused bent: you start by walking in the shoes of your customer, using the software you haven't built yet. The customer in the case of TDD might be you - maybe you'll be consuming the methods of the class you're about to develop in order to develop a higher level class. But that's just a matter of scope and doesn't change the fact that you need to develop from the perspective of the person that will be using that particular piece of software.
We call these prototypical consumption exercises "writing tests", but in Dan's mind that was looking at it the wrong way - it's really focused on the behavior of your software. Thus Behavior Driven Development.
BDD has since morphed into something more than just another way of looking at TDD, providing a textual grammar (a "Domain Specific Language", albeit a small one) for specifying "given these conditions, when I execute this action, then I should have these results". Given, When, Then. Pretty simple.
"Getting the words right", Dan North said. Words being so important and so often dismissed. Getting words wrong (or at least not agreeing on or thinking about the same things when you say something) might be the single biggest source of pain in our industry (indeed, in the world).
This is one of the many reasons why I'm a big proponent of another agile discipline, Domain Driven Design (DDD), is its idea of a Ubiquitous Language.
Anyway, "Given, When, Then". Sort of acceptance criteria-like - thus BDD is often labeled an 'acceptance' testing process. I personally think that boxes into something smaller than it deserves: I think it can be used for unit testing and functional testing and integration testing too.
The idea that you can execute textual user stories is pretty powerful. Done right, it implies no more (or at least minimal) separate "requirements documents" or "test plans" or the dreaded "traceability" documents that often accompany them. That's where the BDD tools come in. And there are a lot of them: RSpec, Cucumber (for Ruby) and JBehave (Java) are probably the most popular.
But it's not about the tools, be clear, but rather the people and their interactions - having more of the latter with the former. If you haven't, take a look: there is a wide world of sports beyond your father's unit testing.
There is also a rockin' talk on "pragmatic Scala" - two of my favorite things. Scala has everything I love: a strong sense of concurrency built into the language ('actors!'), static typing but with a brevity of syntax, a functional bent ('to iterate is human, to recurse divine'), runs on the Java Virtual Machine. Great stuff. Good for you. The details of the language around how you invoke methods and what symbols you can use to name them has resulted in a lot of Scala code that's hard to read, but the idea of Scala is absolutely wonderful. I'm only just thinking in terms of its pragmatic value, with visions of Perl-like obfuscation dancing in my head. But still, check it out.
Subscribe to:
Posts (Atom)
Posts
