Write it,
Run it,
Fix it


Driving development with BDD

Me : Roman Landenband

BDD enthusiast, a craftsman

Who am I

  • Code Monkey
  • Healthy interest into methodologies for improving my skillz
  • Not a methodology "Nazi"
  • Also, a Unicorn! (but don't tell anyone)

Who Are You?


  • Testers?
  • Doing TDD/BDD?

Fellow Engineers..

Attribution: RIA Novosti archive, image #879 / Knorring / CC-BY-SA 3.0

(press down....)

Testing...

source: wikipedia

(press down....)

Testing...

source: wikipedia

(press down....)

Testing...

source: wikipedia

(press down....)

Testing...

source: flickr

(press down....)

Please Test And Report!

source: flickr

Why Should You Care About Testing?

(press down....)

Famous "last" Quotes


  • This little change will surely not break anything..
  • Changes? umm.. there's cake in the kitchen *TAKE MINE*
  • I will just return null..
  • I am the only one who uses this API.. right?
  • Done creating singleton ConfigToolManagerUtility, now I will just add some notes in the header of my UserBeanFactory, others will surely read it..

Buzz Words Corner


  • Enables CI/CD
  • Protects against regression
  • Facilitates refactoring
  • Asserts functionality when updating / upgrading 3rd parties
  • Run subset of tests on live environment, for monitoring
  • Bug reproduction environment

Other Engineers Are Testing... Are You?

Types of Automated Tests

  • Unit Tests
    • test coverage
    • implementation details
  • Acceptance / System Tests
    • functionality of the entire system
  • Performance Tests
    • well.. performance!

OK.. So Tests Are Good, But Why "Test First"?


  • Developer, who wrote the code, knows best how / where it may break
  • Encourages (ahem forces)
    • encapsulation
    • deterministic system setup / teardown
    • self documenting
    • good public APIs

TDD encourages simple designs and inspires confidence

Kent Beck

Why BDD


  • Value / feature driven
  • Better fit for Agile
  • Focus on behavior, not code coverage
  • Encourages common ("domain specific") language for communication
  • User stories are aligned with delivered features

Start Using It Today

  • Collect requirements
  • Formulate user stories / scenarios
  • Dumb down the user stories to be as small as possible (max 1 sprint)
  • Design: HLD, wire frame etc..
  • Code up the test according to the story (possibly dumb down the story some more)
  • Fail the test.. implement the functionality.. make it pass..
  • Refactor and abstract code/tests, build smart test "helpers" to simplify test setup

In Which Project Would I Use BDD?

Everywhere really!

  • Frontend
  • Backend
  • Mobile
  • Algorithms

When Is BDD Less Effective

  • When you are less effective using it (while learning)
  • New framework / environment / tools...
  • When "playing around with code"

"Domain Specific Language" is formulated between "stake holders". Optimally one would like to preserve the nuances of said language while designing APIs (be it public or implementation specific code).

The key to BDD is explicitly stating what you want to get from the code your about to write. If your already doing Agile, and your working with "stake holders" to create user stories, it should be easy to see how these translate into actual code

User Stories


Two common formats:

  • As a... I will... So that...
  • Given... When... Then...


(press down....)

  • As a user, I will be able to choose to stay signed in when logging in, so that I wont have to type my password next time
  • As an API client, I will be able to update my e-mail address
  • Given a dashboard user, When some filters were selected, and the clear filters button is pressed, Then filters are reset
  • Given a dashboard user, When some filters were selected, and the clear filters button is pressed, Then content is reloaded
  • As a library user, I will be able to receive the list of files given a directory
  • As a library user, I will get an exception when I provide a path which is not a folder

Let's see some code examples...


(press down....)

Sorting Algorithm

								
//===  Sorter.js
var MergeSort = require("MergeSort");

var Sorter = {
	"sort" : function(inArray){
		return MergeSort.sort(inArray);
	}
}

//=== SorterSpec.js
var Sorter = require("./Sorter")

// As a code user, I will have a generic Sorting API
describe("Sorting"){
	it("simply returns a sorted array"){
		var provided = [1,2,3,4,5];
		expect( Sorter.sort(provided) ).toEqual( provided )
		// replace QuickSort
	}

	it("sorts a reverse unsorted array"){
		expect(Sorter.sort([5,4,3,2,1])).toEqual([1,2,3,4,5])
	}
}
								
							

Sorting Algorithm 2

Just in - we need a space conserving algorithm!

We will be using the QuickSort algorithm instead

								
//===  Sorter.js
var QuickSort = require("QuickSort");

var Sorter = {
	"sort" : function(inArray){
		return MergeSort.sort(inArray);
	}
}

//=== SorterSpec.js
var Sorter = require("./Sorter")

// As a code user, I will have a generic Sorting API
describe("Sorting"){
	it("simply returns a sorted array"){
		var provided = [1,2,3,4,5];
		expect( Sorter.sort(provided) ).toEqual( provided )
		// replace QuickSort
	}

	it("sorts a reverse unsorted array"){
		expect(Sorter.sort([5,4,3,2,1])).toEqual([1,2,3,4,5])
	}
}
								
							

Example From Real Life

CoffeeScript project
Scala project
Travis failed output

Other Useful Tools

Mocking

								
var PsuedoMocker = require("PsuedoMocker")
var Networking = require("./NetworkingSorter")
var Scraper = require("./Scraper")

// As a code user, I will have a generic Sorting API
describe("Scraper"){
	it("fetches something from the web"){
		var someContent = "
aaaa
" var mockedNetwork = Mocker.mock(Networking); mockedNetwork.overide("get", function(){ return someContent }) var scraper = new Scraper(mockedNetwork) expect( scraper.scrapeByClass("http://somewhere.com","something") ).toEqual("aaaa"); } }

Dependency Injection

  • Factories (using 3rd parties to override what is provided in run time)
  • Mix-ins (for languages that support it - AKA "Cake Pattern")
  • Constructor DI

Other resources


Kent Beck's blog Nice overview of TDD

Kent Beck's TDD book Google!

Have you starting writing BDD after my talk? Have more questions? let me know!

shoot me an e-mail
Grab the slides

HAPPY HACKING