What does BDD really stand for?

Filed under: BDD, Cucumber, Executable specification, — Tags: Behaviour-Driven Development, Gherkin — Thomas Sundberg — 2018-04-17

BDD is the acronym for Behaviour-Driven Development. It is a way to describe the behaviour of a system and a way to make sure that it is developed to behave as it should.

BDD is used for understanding what to create and for verifying the result.

Business-Driven Development

But BDD could also be the acronym for Business-Driven Development. BDDers work really hard to bridge the communication gap between development and business. We really try to involve the business people in the development. We value their input and love discussing concrete examples describing what the system should do. How it is done is less important when understanding what really matters for the business. Focusing on the what and not the how is a differentiator between communicative developers and regular developers.

(more...)

Testing stage 2018

Filed under: Cucumber, Executable specification, Presentation, Selenium, — Tags: Behaviour-Driven Development, Gherkin, The four rules of simple design — Thomas Sundberg — 2018-03-26

In April I will be talking at Testing stage in Kiev, Ukraine

I have two sessions:

They are connected in the sense that they are both about how to implement the support code you need for your test automation initiative. As a developer, I know that how you implement code is really important. It is ultimately a matter of maintainability. And maintainability is probably the most important property a piece of code can have after being correct. Code that can't be maintained will create problems for you during the entire lifetime of your product.

(more...)

Gherkin scenarios - some good properties

Filed under: BDD, Cucumber, Executable specification, — Tags: Behaviour-Driven Development, Gherkin, Scenarios — Thomas Sundberg — 2017-05-29

Are there any global properties that a Gherkin scenario should fulfill? A short answer is, no.

A longer answer is that there are some properties that are good and probably useful in many different contexts.

(more...)

How do you create a good specification?

Filed under: BDD, Cucumber, Executable specification, Requirements, — Tags: Behaviour-Driven Development, Gherkin, Good specifications — Thomas Sundberg — 2017-02-26

A good specification is

An interesting question is "How do you create a good specification?" There are obviously a lot of different ways to end up with a good specification. You may be lucky and randomly end up with something good. There are, however, better ways than to rely on luck.

(more...)

What is the difference between a specification and a good specification?

Filed under: BDD, Cucumber, Executable specification, Requirements, — Tags: Behaviour-Driven Development, Gherkin, Good specifications — Thomas Sundberg — 2017-01-30

What makes one specification a bad specification and another specification a good specification? What is the fundamental difference between two specifications?

(more...)

Cucumber and Gherkin are not about flexibility

Filed under: BDD, Cucumber, Executable specification, — Tags: Behaviour-Driven Development, Gherkin — Thomas Sundberg — 2016-12-04

Sometimes I see questions asking for flexibility in Gherkin, the language used by Cucumber. The purpose is often to remove duplication. An example may be this Stackoverflow question

Removing duplication is often a very a good thing. It is, however, sometimes better to keep duplication and gain clarity and readability.

(more...)

Why Cucumber?

Filed under: Cucumber, Executable specification, Test automation, — Tags: Automated acceptance criteria, Automated acceptance tests, Collaboration, Concrete examples, Cucumber-jvm, JUnit, Readability, Requirements — Thomas Sundberg — 2014-03-30

Before I can try to motivate why you should use a tool, let me define what it is and what it does.

What is cucumber?

Cucumber is a tool for collaboration and testing. It is used to create examples of behaviour that are executable. Creating examples in a collaborative way emphasize close cooperation between business analysts, testers and developers. The examples they come up with can be used as acceptance tests for the system being developed. It can be used as a testing tool where the tests are defined in a business friendly language while still being executable.

Goal

Our goal is to create a common understanding of the problem and therefore simplify the communication between all parties involved. We would also like to get something that is possible to use for automating the verification of the resulting program. That is, use as a base for test automation of the system.

(more...)

Pages

About
Events
Why

Categories

Agile
Automation
BDD
Clean code
Continuous delivery
Continuous deployment
Continuous integration
Cucumber
Culture
Design
Executable specification
Gradle
Guice
J2EE
JUnit
Java
Linux
Load testing
Maven
Mockito
Pair programming
PicoContainer
Presentation
Programming
Public speaking
Quality
Recruiting
Requirements
Scala
Selenium
Software craftsmanship
Software development
Spring
TDD
Teaching
Technical debt
Test automation
Tools
Web
Windows
eXtreme Programming

Authors

Thomas Sundberg
Adrian Bolboaca

Archives

Meta

rss RSS