Test First Approaches With Test Driven Development and Behavior Driven Development
Gil Zilberfeld will give a small workshop on test first approaches and the basics of Test Driven Development (TDD) and Behavior Driven Development (BDD) at the Agile Practitioners conference:
Test-First is a great tool. It creates better understanding and productivity in the team. The result is high quality code – both in terms of early success in finding bugs and implementing features correctly.
InfoQ will be covering the Agile Practitioners 2016 conference with news, Q&As and articles. This conference is held on January 26-27 in Tel Aviv, Israel:
(...) our theme this year [is] Hands-On Agility. We know that there’s no teacher like experience, and we’ve got many workshops and practical talks where attendees can experience, hear and see how agile activities are done in many successful organizations.
InfoQ interviewed Zilberfeld about the benefits that a test first approach can bring, the concepts of TDD and BDD and examples of teams using BDD and TDD, and how you can explore BDD and TDD without doing any coding.
InfoQ: What are the benefits that a "test first" approach can bring?
Zilberfeld: Test Driven Development famously started by Extreme Programming practitioners in the late 90s. But truth is that people were writing tests before code decades before.
The idea is this: When programmers write code, they are usually solving complex problems in code. However, the result is usually complex as well, and contains much more than is actually needed to solve the problem (assuming the important stuff is coded).
That means more code to test. Testing sometimes requires changing the "already working" code, which introduces risks. What eventually happens is either no testing at all, because there was no time left, or suboptimal testing, because we couldn’t get the coverage we wanted.
Test First defines what needs to work. It defines what code we need to write to solve specific problems, because we have a definition in a form of a test. It’s fairly simple to know if we have working functionality just by running the tests.
Working this way results in much more coverage, because testing becomes a first-class development activity, rather than getting pushed to the end.
In addition, when writing these tests, and specifying the scenarios, we explore the problem space more, because many questions will come up. In Test-After these discussions sometimes never happen, and the developers code what they think, rather than what the solution needs.
InfoQ: Can you briefly explain the concepts of Behavior Driven Development (BDD) and Test Driven Development (TDD)?
Zilberfeld: In both TDD and BDD, you first break down the problem into scenarios which are examples. Our minds find it easier to concentrate on small scenarios, rather than tackle a big, complex problem.
Then you start the famous Red-Green-Refactor cycle like this:
- Write a failing scenario. It fails because of compilation, or because the code doesn’t exist. Regardless, the test is an example of how the code is used by an external module.
- Make the test pass. The focus is on working functionality, not on form, that means write the minimal implementation that passes the test. To take it further, it should pass the entire suite of tests we’ve written until now.
- Improve the code. Now that everything is green, we can rewrite the code, with the safety net of tests. If we break something, we’ll know immediately.
Breaking problems to smaller parts, then developing the needed code incrementally, also puts much needed brakes in the process. It helps us think about scenarios that we’re missing, as opposed to "we know what the solution looks like".
BDD, that started in the mid 2000s, took TDD one step further to the product space. By using examples of the product usage, we can develop just the code that is needed for these scenarios. We can focus on the scenarios that are important to the business. We can then use TDD to write the actual code.
The biggest benefit of BDD is the conversations. If you put the "Three Amigos" in a room – A business analyst, a developer and a tester – to discuss examples of behavior we want to see, we get the best of all perspectives, to raise and solve issues before writing a single line of code.
And that’s what BDD looks like – discussing examples of agreed behavior. These examples can be written as automated tests (but that is not required), then coded to make the tests pass, and then refactor the code.
Obviously, the level of detail of BDD scenarios is broader than the finer TDD tests. I find that while they correlate in some ways, writing tests in TDD, and BDD scenarios requires different set of skills.
InfoQ: Do you have some examples on BDD and TDD from teams that you worked with?
Zilberfeld: With BDD, there are differences like who writes the scenarios, but with most teams I work with, the testers write them. The examples are discussed prior to the writing the code. The testers and developers work in parallel – testers on their automated high level tests, and the developers on their code and their unit tests (test-first or not). The scenarios are reviewed once ready. Then at some point there is integration between the developers and the testers, to make sure the tests pass.
BDD and TDD are very "agile" in their spirit, making it very visible if a scenario is "Done" or not. BDD scenarios "fit" into a sprint, otherwise, it’s an indication that the stories are too big.
TDD is a bit different from a point of implementation. After some training, developers come to terms with the code waiting for them at work. Usually that’s legacy code, that is different than clean Test-First code.
I jokingly refer to the last D in TDD as discipline. Because that matters most in order for a test-first implementation. It’s hard, it’s different than what we were taught, and we need our team to support us, way before we see the value. That’s why most team don’t end up doing TDD, but settle for test-after tests.
Those that make it through the rough beginning, start cleaning their code and adding more coverage. Code becomes simpler to maintain. And from a social point of view, new developers on the team enter TDD as the "this is how we work here". It’s a positive feedback loop.
InfoQ: Can you give a sneak preview to the InfoQ readers of your workshop at the Agile Practitioners conference? How will you explore BDD and TDD without coding with the attendees?
Zilberfeld: There’s a story behind this workshop. A few years ago I was planning to do my "TDD a spaceship" workshop at Belgium Testing Days (and I’m going to do it at Agile Testing Days Netherlands in March). It’s designed for developers, but the people who came were testers, with minimal coding experience. So the workshop turned to explaining the ideas of test-first, without actual coding. Naturally, I gravitated to Star Wars examples, and we talked and drew stories, and discussed acceptance criteria and how we will know that the story is done.
After that workshop, I thought about how to do this in an experiential manner. As luck would have it, I was introduced to a GIF making software tool, and suddenly we had a tool that can help. It’s a creational tool, so people can "script" their film in advance, build and run it and they get feedback immediately.
The cool thing, we can apply agile development principles and experiences. There’s always a difference between what you imagined your movie to look like, and the actual result. So we build a new version.
Another example is about dealing with legacy code. One of the exercises is about replacing an actor in the movie, but because the movie is already edited, we can only add scenes in the beginning or the end. This idea of how changing requirements clash with code that is already built, that you can’t take it apart is very enlightening.
InfoQ: You are also one of the organizers of the agile practitioners conference. Can you tell us something about the conference program?
Zilberfeld: It’s the 5th year that we run the conference, and it’s been growing in size and quality from its inception. It was ranked the best agile conference in Israel for a reason.
We have centered the conference around the "hands-on" theme. We’re going to have full day tutorials, small workshops and even the talks are of practical use. We aim for people to experience, then go back to work and starting to do what they have learned.
We’ve got content for every type of attendee – scrum masters, testers, developers, product managers, team leaders and any role you can think of. But the conference is not just about broadening your knowledge in your role. It’s about you learning about what other people do, in the good ol’ "hands on" fashion.