Trace: » specbyex.html

[hemmerling] Specification by Example, Modelling by Example


Process and Proceedings...

Modelling by Example

Specification by Example

Behaviour Driven Development ( BDD )

Connextra Format

"Given, When, Then"


Acceptance Test-Driven Development ( ATDD )

Domain-Driven Design ( DDD )


Design Patterns & Design Principles

Experts, Gurus and Evangelists

Table-Driven Testing vs. Data-driven Testing

Keyword-Driven Testing ( KDT ) / Table-Driven Testing ( TDT ) / Action Word Based Testing ( AWBT )

Data-driven testing ( DDT )

Test Driven Development vs Test-First Programming

Test-First Programming

Test Driven Development / Extreme Programming ( XP )


Emergent Design

Free Software for Keyword-Driven Testing / Table-Driven Testing / Action Word Based Testing

FIT, SLIM & Fitnesse

Fitnesse for Java

FIT & FitLibrary for Java


PyFIT Python

Fit Sharp, FitNesse.DotNet for .NET


The Tool

Robot Framework

The Tools


Documentation, Tutorials


Some other free Software for Keyword-Driven Testing / Table-Driven Testing / Action Word Based Testing

BDD Tests written in Natural Text & Natural Text Parsing


JBehave for Java

The Tool
Demo Project "Shopping Cart"


Behave for .NET

Bhat for PHP

Python Behave

Serenity BDD

Serenity BDD

Spock, Gep

The Tools
Selenim with Geb
Mocking by Mock()

Frameworks for writing Matcher Objects


Cucumber, a Ruby Tool

Behaviour Driven Development for Javascript


  • Chai - “A BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework”.

Pure Javascript Cucumber


Pester - BDD Framework for Windows PowerShell

Some other BDD Tools for Python

Cucumber for Python




  • The OpenSource Github "heynemann / pyccuracy" - “A Behaviour-Driven-Development-style tool written in Python that aims to make it easier to write automated acceptance tests. It improves the readability of those tests by using a structured natural language – and a simple mechanism to extend this language – so that both developers and customers can collaborate and understand what the tests do”.


  • Python Package Index "pytest-bdd" - “BDD library for the py.test runner”, “ytest-bdd implements a subset of Gherkin language for the automation of the project requirements testing and easier behavioral driven development. Unlike many other BDD tools it doesn't require a separate runner and benefits from the power and flexibility of the pytest. It allows to unify your unit and functional tests, easier continuous integration server configuration and maximal reuse of the tests setup”.


Serverspec - RSpec Tests for Server Configurations

  • Serverspec - RSpec tests for your servers configured by Puppet, Chef or anything else - “With Serverspec, you can write RSpec tests for checking your servers are configured correctly. Serverspec tests your servers' actual state by executing command locally, via SSH, via WinRM, via Docker API and so on. So you don't need to install any agent softwares on your servers and can use any configuration management tools, Puppet, Chef, CFEngine and so on. But the true aim of Serverspec is to help refactoring infrastructure code”.
  • GitHub "serverspec" - “RSpec tests for your servers configured by Puppet, Chef or anything else even by hand”.

Some other free Software for Acceptance Tests

Commercial Software

Commercial Online Services

  • The commercial online service Relish - “Living documentation. Combine your product's documentation with cucumber tests. Publish, browse, search & share on Relishapp…”.


Literature - Specification by Example


Resources for the Book "Specification by Example"

Chapter 2 - Key Process Patterns
Chapter 3 - Living Documentation
Chapter 4 - Initiating the Changes
Chapter 5 - Deriving Scope from Goals
Chapter 6 - Specifying collaboratively
Chapter 7 - Illustrating using Examples
Chapter 8 - Refining the Specification
Chapter 9 - Automating Validation without changing Specifications
  • Suggestion by Gojko Adzic: “Avoid automating existing manual test scripts”.
  • Suggestion by Gojko Adzic: “Don't check business logic though the user interface.”Traditional test automation tools mostly work by manipulating user interface objects. Most automation tools for exeutable specifications can go below the user interface and talk to application programming interfaces directly ( API ) .
  • Suggestion by Gojko Adzic: “Automate below the skin of the application. Workflow and session rules can often be checked only against the user interface layer. But that doesn´t mean that the only option to automate those checks is to launch a browser. Instead of automating the specifications through a browser, several teams developing web applications saved a lot of time and effort going right below the skin of the application - to the HTTP layer”.
  • Web Automation by direct HTTP automation:
  • Gojko Adzic suggests: “Specify user interface functionality at a higher level of abstraction”.
    • Gojko Adzic discovered: “Automating user interfaces. Almost all the teams I interviewed made the same mistake early on. They specified tests intended to be automated though user interface as series of technical tips, often directly writing user interface automation commands in their specification” :-(.
    • Pierre Veragen realized “User interface tests were task oriented ( click, point ) and therefore rightly coupled to the implementation of the GUI, rather thant activity oriented.... FitNesse tests wre organized according to the way UI was set up”.
      • “When the UI was updated, all these tests had to be updated...”.
      • “A small change to the GUI, adding a ribbon control, broke everything. There was no way we could update the tests”.
    • Lance Walton explains:
      • “The next stage was to understand that the workflow still had to do with the solution we designed, so actully let's forget about workflow and focus on what the user is trying to achieve”.
      • “So we had pages that contained the details, then we had the task level above that, and then we finally had the goal that the user is trying to achieve”.
    • Gojko Adzic suggests: “Avoid recorded UI tests”, “Many traditional test automation tools offer record-and-replay user interface automation”, “This is one of the areas where automation of executable specifications is quite different than traditional automatied regression testing”.
    • Gojko Adzic defines “Three level of user interface automation”.
      1. Technical activity level - What are the technical steps required to exercise individual workflow steps ?
        • For example: Open the shop home page, log in with “test user” and “testpassword”, got to the ”/book” page, click the first image with the “book” CSS-class, wait for the page to load, click the Buy Now link, and so on.
      2. User workflow level - How can a user exercise the functionality through the UI, on a higher activity level ?
        • For example: Put two books in a shoppoing cart, enter address details and verify that delivery options include free delivery.
        • The automation layer should handle the workflow level by combining blocks composed at the technicial activity level.
      3. Business rule level - What is the test demonstrating or exercising ?
        • For example: Free delivery is offered to customers who order two or more books”. Specifications should be described at the business rule level.
Chapter 10 - Validating frequently
Some other Articles

Literature - Acceptance Test-Driven Development ( ATDD )

Literature - Behaviour Driven Development ( BDD )

Literature - Domain-Driven Design ( DDD )

Literature FIT & Fitnesse

Literature - Agile Behaviour Driven Development

  • "Agile Software Development eBook", sponsored by IBM - “This eBook begins with an overview of the Agile Scaling Model (ASM), a framework used to provide context to the plethora of agile methodologies available today”.


Forums, Newsgroups

en/specbyex.html.txt · Last modified: 2023/11/24 16:03 (external edit) · []
Recent changes RSS feed Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki