Driving Development Using Examples Sai Venkatakrishnan Developer - PowerPoint PPT Presentation

Driving Development Using Examples Sai Venkatakrishnan Developer in Test, Thoughtworks http://developer-in-test.blogspot.com Fork me at - http://github.com/saivenkat Follow me at - http://twitter.com/sai_venkat

Introduction  Problems we are trying to solve. How to build the right thing?   What do we get out of this?  Gotchas  Coding time :)

Are we building the thing right as well building the right thing?

Intention and Implementation

Broken Language

Broken Language  Team doesn't use a single language (Ubiquitous language).  Like Telephone or Chinese Whispers game  People interpret things in their own way  Things lost in translation

Is obvious really obvious?

Small misunderstanding can cost a lot of money Mars Climate Orbiter Crash ● Total project cost was $327.6 million ● The metric/imperial mix-up that destroyed the craft was caused by a software error back on Earth. ● The software was working in pounds force, while the spacecraft expected figures in newtons; 1 pound force equals approximately 4.45 newtons.

Are we there yet? Is there a common definition of done?

Evolution of codebase

Production Release after manual testing (Scripted Testing)

Knowledge Lost in Time

How many points are there?

What do we need to develop?

Client name - Nile book store  A famous web bookstore. Offer during 2nd year celebration.   Any customer who has been buying for past 2 years, living in US and bought books for worth 500 $ will be awarded 300$ gift coupon.  Any customer who has been buying for past 2 year and a non US customer and bought books worth 300 $ will get 250 $ worth gift coupons.  Any customer who has been buying for past 1 year, and living in US and bought books worth 1000 $ will get 200 $ worth gift coupons.

How to build software that matter?

Requirement – Test Paradox As formality increases, tests and requirements become indistinguishable. At the limits tests and requirements are equivalent – Uncle Bob

Tests as Requirements

Specification workshop  Discuss and distill requirements, identify gaps, expand examples and get common definition of done  Should include product owner, domain expert, tester, developer.. or the whole team :)  Product owner describes his requirement and system beavior in form of concrete examples  Team questions and discusses the requirements, find alternative ways, and edge cases  Ends when team reaches an agreement on sufficient number of examples of happy path and edge cases

Specification workshop  <Picture of table with team discussing>

Specification Development  The tester with developer creates fixtures to turn the examples into executable acceptance tests.  The tests initially fail, since the feature is not yet implemented.  The tests may target the scriptable interface (API) or user interface (or both).  Only the necessary functionality to pass the tests is implemented (and no more).  This doesn't in anyway change the normal TDD cycle.

Demonstrate  A feature which passes the acceptance test has just crossed half the bridge.  More tests in form on Exploratory testing, performance, usability and more are needed  A feature is not done until it is deployed and used in production (Continuous Deployment)

What do we get out of this?  Executable and living Specifications  Better test scripts run as part of build (Side effect)  Shared understanding of domain and ubiquitous language  Better understanding of intricasies of domain (Helps in Domain Driven Design)  Better clarity on what we are building and are we doing it right?  Better consensus on when we are done

Gotchas Existing specifications are often changed   You're tied to an implementation Lots of "execute" or imperative commands   You're writing a script Complicated instrumentation   You're testing too much in one go Complicated fixture code   Your fixture code is verbose and hard to follow Examples all have the same structure   Your examples are too generic

Too much automation

Test Automation Pyramid

Robot Framework Introduction

Test Automation Framework ● Implemented using Python language ● Python is the recommended language to create test libraries and otherwise extend the framework ● Runs on JVM on top of Jython ● Possible to implement test libraries using Java

Keyword Driven Approach

Data Driven Approach

Fixture Implementation

Higher Level Keyword

Variables

Tagging  Free metadata to categorize test cases  Statistics by tags collected automatically  Select test cases to be executed  --include and --exclude options  Specify which test cases are considered critical 35

Clear Reports

Similar Tools  Fit and FitNesse  Concordion  BDD Frameworks  should_dsl - http://github.com/hugobr/should-dsl  Behavior - http://pypi.python.org/pypi/Behaviour/0.1a4