BDD is powerful stuff, and it's much more powerful when your product owner understands the benefits .
We love having product owners at BDD Kickstart . The first day is all about the collaborative aspects of BDD where we learn how to break down and describe requirements using examples. We find that product owners really enjoy it.
That's why we're announcing a special promotion for our next public course in. Use the discount code " BYPO" …
I think balance is important. Whenever I teach people about BDD or automated testing , we make a list of the costs and benefits of test automation.
The lists typically look something like this:
thorough analysis of a requirement
confidence to refactor
quick feedback about defects
living / trustworthy documentation
frees up manual testers for more interesting exploratory testing
time spent leaning how to write a test
time spent writing the test
Naming things is hard. Witness things that developers have named and then struggle to explain because words and people are weird:
TDD sounds like it's about testing, but it's really a design technique.
BDD sounds like it's about what code does, but it's really a communication discipline.
Outside-in development sounds like a way to discover the design of software, but it's really a technique for building software using a fractal todo list.
This is the single most powerful behavioural shift I have seen in teams adopting BDD. Simply by getting the business users, the analysts, the testers and the developers to adopt this vocabulary of "given/when/then", they discover that a world of ambiguity falls away.
§ Top 10 Weird APIs , serving your facts, making fake calls, and …
I made a presentation on Refactoring & BDD atback on 10/09/2012. I put my slides and notes from the presentation up on Deck.
Some quick takeaways ...
The less your problem is understood, the more complicated your solution is likely to be. This is one of the reasons why we refactor code - we increase our understanding of the problem domain and increase our abilities to apply solutions to the domain as time goes by.
After I left Object Mentor, RSpec was part of my day to day work on Ruby applications, but most of my work on its maintenance moved to my spare time. This was fine at first, as I had the support of employers and family, but I found myself doing less and less of pretty much everything else that I enjoy and learn from.
…But 'tests' and test-driven development are not the same animal. TDD (or BDD) is a process that will deliver not just superior code, but massive accrued time savings over the life of your project. With experience, it will also provide immediate time savings in almost every case: when you're doing it right, it's usually faster to write the tests and the code than just the code. I'll explain the difference, and walk through some concrete examples.
I'm a lifetime …
require 'minitest/spec' describe Meme do before do @ meme = Meme. new end describe "when asked about cheeseburgers" do it "should respond positively" do @ meme . i_can_has_cheezburger ?. must_equal "OHAI!" end end describe "when asked about blending possibilities" do it "won't say no" do @ meme . does_it_blend ?. wont_match / ^no / i end end end
I'm excited to be presenting on Behavior-Driven Objects at the Agile conference website : One of the original ideas behind BDD was that testing should be about behavior at all levels. Effectively, all automated tests can be viewed as "functional tests" of entry points, be they user facing or internal, crossing procedural boundaries or not. In this talk we'll explore approaches …& BDD eXchange in on Monday, October 1st (details below). From the
§ BDD meets Pre-emptive commit comments :
Rule #1: write commit comments before coding
Rule #2: write what the software should be supposed to do, not what you did
§ Hall of Shame of Skeuomorphism . May you never have to work on an app that's featured there.