Index

Acceptance test-driven development (ATDD)

collaboration in, 51

in friendly test automation, 162–66

gaps in, 149

successful, 183–85

support codes and, 49–50, 59–60, 70

vs. TDD, 118

test automation and, 162–66

Acceptance test suite, 111–12, 147

Adzic, Gojko, 121, 148, 154–55, 163, 187

Agile-friendly automation, 156, 161, 163, 177, 178, 193

Agile Software Development — Patterns, Principles, and Practices (Martin), 124

Agile Testing (Crispin and Gregory), 150

Airport Parking Lot test cases. See also individual headings

Automating Remaining Parking Lots test case, 41–46

Parking Cost Calculator Workshop test case, 3–15

Valet Parking Automation test case, 17–39

Alice’s Adventures in Wonderland (Carroll), 147

Alpha tests, 150, 151

Appelo, Jurgen, 150

Arrange-Act-Assert format, 136

ArrayFixture, 135

Automating Remaining Parking Lots test case, 41–46

durationMap for, 43–44

economy parking lot, 44–45

economy parking lot examples, 44–45

short-term parking lot, 41–44

short-term parking lot examples, 41–42

step definitions after generalizing, 42

summary, 46

Automation, 161–68

collaboration on, 164–66

domain discovery, 166–67

domain-specific test language in, 162

keyword-driven, 137–39

summary, 167–68

test, developing, 170–72

user-friendly, 162–64

Behavior-driven development (BDD), 131, 132–33, 187

Beta tests, 150, 151

Boundary conditions, 142–43

Boundary values, 144–45

Business-facing tests, 150, 152

CalculateFixture, 134

Camel-casing, 137, 139, 191, 194, 199

Carroll, Lewis, 147

Clean Code (Martin), 170

Clojure, 163

Code. See also individual codes

library, 199

production, 121–22

refactoring, 176

supporting, 59–60

Code in Light States test case, developing, 66–70

deciding which one to return based on previous state, 69

final test table for car states, 69

first example passes, 68

first flow after implementing light configurations, 70

first support code class, 66

FitNesse result after creating class, 67

FitNesse test turns from yellow to red, 67

folder layout in, 66

hard-coded return value of nextState method, 68

second test expressing state transition from red and yellow to green, 69

support code class with empty method bodies, 67

Cohn, Mike, 158

Collaboration, 50–52, 153–59

in ATDD, 51

on automation, 164–66

Power of Three, 153–55

summary, 159

trawl requirements, 158–59

workshops, 155–57

ColumnFixture, 134

Command/Query-Separation, 98

Concordion Framework, 163

Continuous integration (CI)

in domain discovery, 121

plug-ins for, 184

in software delivery, 51

test automation code and, 139

test failure in, 147

in Value Parking Automation test case, 18

Controller, driving. See Driving controller in First Crossing test case

Controller specifications in First Crossing test case, 93–94

happy path scenario for controller state transitions, 94

state transitions to consider, 94

Copeland, Lee, 143

Crispin, Lisa, 147, 150, 155

Cucumber, 163, 187–89

feature files, 187–88

production code, 189

Ruby and, 17, 163, 187, 188

step definitions, 188–89

Decision tables, 134–35, 192

FitNess SLiM, example of, 192

function of, 58

query tables combined with, 136, 193

in refactoring, 104

setup table preparing three different accounts, 134

support code for, 194

in test cases, 61, 65, 94, 98, 104

valet parking tests expressed as, in SLiM, 58, 134

De Florinier, Annette, 163, 187

De Florinier, David, 163, 187

Domain, discover, 120–21

Domain discovery, 166–67

Domain partitioning, 143

Domain-specific test language, 162

Domain testing, 143–44

Driving controller, 94–118

Driving controller in First Crossing test case, 94–118

body for controller glue code class that switches state, 96–97

first empty body for controller glue code class, 95–96

first invalid configuration, 99

first LightState changed in execute method, 99

first test for, 94

happy path tests for controller that

switches first light only, 96

permutated invalid configurations put into table, 102

second light state stored in field, 97–98

setting of warning configuration extracted from if body, 101

UNKNOWN light stats supported, 103

validation method extracted from if clause, 100–101

validation step added to controller before switching light states, 100

Equivalence classes, 143–46

Evans, Eric, 48, 142

Examples, 129–52

cutting, 146–48

format of, 130–42

gaps, 149–51

refining, 142–46

summary, 151–52

Exploratory tests, 136, 149, 150, 151, 152

Extract Superclass, 176

Feature, 17

Feature files in Cucumber, 187–88

First Crossing test case, 93–118

controller specifications, 93–94

driving controller, 94–118

refactoring, 103–18

summary, 118

Fishnet scenario, 158

FitLibrary, 134, 135, 137, 163

CalculateFixture in, 134

FitNesse and, 163

FitNesse, 191–94

architecture, 192

in First Crossing test case, 93–118

FIT and, 163, 191, 192

introduction to, 55, 58–59

in Light States test case, 61–91

link added to front page, 63

shell output from starting for first time, 62

SLiM tables and, 58–59, 163, 191–93

support code, 193–94

welcome screen when starting for first time, 62

wiki structure, 58, 191–92

Folder layout

in Light States test case, 66

in Valet Parking Automation test case, 21

Format, 130–42

behavior-driven development, 131, 132–33

glue code and support code, 139–40

Internet search, basic, 132

keywords or data-driven tests, 131, 137–39

right, 140–42

tabulated formats, 131, 133–37

Framework for Integrated Tests (FIT), 58, 133

ActionFixture in, 137

ColumnFixture in, 134

FitLibrary and, 134, 135, 137, 163

FitNesse and, 163, 191, 192

GPLv2 model and, 58, 191

RowFixture in, 135

Freeman, Steve, 176

Gaps, 149–51

Getting Started test case

FitNesse, 58–59

refactoring of traffic lights, 56, 57

summary, 60

supporting code, 59–60

traffic lights, 55–56

unit test in Java, example of, 59

Valet Parking tests expressed as decision table in SLiM, 58–59

Given-When-Then format

alternative to, 136

in BDD, 131, 132

in Cucumber, 163, 187

script tables and, 140, 193

Glue code

in First Crossing test case, 95–118

format, 131, 139–40

implementing for test automation, 95–118

in refactoring, 107–18

signature of EJB2 service executor for Needle Eye pattern, 124

summary, 126

test, 122–24

in Valet Parking Automation test case, 17–18, 20, 21

value, 124–25

GPLv2 model, 58, 191

Green Pepper Framework, 163

Gregory, Janet, 150, 155

Groovy, 163

Growing Object-oriented Software Guided by Tests (Freeman and Pryce), 176

Happy path scenario, 47, 93–94, 96, 103

Headless Selenium server, 18

Initializers in Valet Parking Automation test case, 26–31

duration map in, 26–27

extracted method for filling in parking durations, 28–30

final version of ParkCalcPage for

initialization steps, 30–31

leaving date and time, 28–29

leaving date and time filled into form fields, 28–29

selecting right parking lot entry from dropdowns, 26

starting date and time filled into form fields, 27

Integrated development environments (IDEs)

in domain discovery, 121

Java, 66

in keyword-driven automation, 139

packages in, 71

in refactoring glue code, 109, 111

refactoring support and, 139, 176–78

setting up and configuring, 66

Intent-revealing tests, 123, 141

Intermodule integration tests, 150

Java, 193

in Cucumber, 163

FitNesse in, 163

in Robot Framework, 195

unit test in, example of, 59

for writing support code for SLiM tables, 193–94

JBehave Framework, 163

JUnit, 59–60, 72–74, 79, 112

Just-in-time requirements trawling, 159

Jython, 195

Kaner, Cem, 143

Kerievsky, Joshua, 170

Keywords

in automation, 137–39

extracting, 179–80

format, 131, 137–39

in integrated development environments, 139

in Robot Framework, to define test cases, 193, 196

scenario tables as, 137–38, 184

in test automation code, 138

Then, 19, 187

When, 19, 187

Library code, 199

Light States test case, 61–91. See also individual headings

code, developing, 66–70

FitNesse in, 61–91

refactoring, 70–90

state specifications, 61–62

summary, 90–91

Light States test case, first test in, 62–66

expressing state transition from red to red and yellow, 65

FitNesse result from, 66

FitNesse welcome screen when starting, 62

root suite of traffic light examples, 64

shell output from starting FitNesse, 62

TrafficLightStates suite, contents of, 65

Listening to test, 172–76

economy parking lot automated examples, 174

setup table preparing account hierarchies with hidden tariffs and products, 175

verbose example for parking lot calculator, 173–74

Marick, Brian, 150

Martin, Robert C.

Agile Software Development — Patterns, Principles, and Practices, 124

Clean Code, 170

Simple List Invocation Method (SLiM), 133, 191

Meszaros, Gerard, 170

Nonfunctional requirements, 155

North, Dan, 132

.NET, 163, 193

Page objects, 184, 189

Pairing, 25–35

checking results, 31–35

initializers, 26–31

Pairwise testing, 145–46

Parallel component, 70

Parameterized tests, 59, 73–74, 112, 116

Parking Cost Calculator Workshop test case, 3–15

economy parking, 6–8

economy parking examples, 7, 11

essential examples, 9–12

long-term parking, 6–8

long-term parking examples, 8, 9–10, 11

short-term parking, 5

short-term parking examples, 5, 12

summary, 12–15

valet parking, 3–4

valet parking examples, 4, 13

Parking lot calculator. See also Parking Cost Calculator Workshop test case

business rules for, 3

extended durationMap, 38, 43

final version for first test, 34–35

final version for initialization steps, 30–31

library for, 22

mockup of, 25

page, 28, 38, 151

Robot Framework and, 196–98

support code for, 18

test executed by, 32

verbose example for, 173–74

PHP, 163, 193

Power of Three, 153–55

business perspective, 153

introduction to, 153–55

mediation between perspectives, 153, 154

technical perspective, 153

Practitioner’s Guide to Software Test Design, A (Copeland), 143, 152

Production code, 121–22

collaboration in, 51

in Cucumber, 189

developing, 189

in domain discovery, 120–21

driving, 121–22

TDD used for, 71

value in, vs. glue code, 124

Production code, drive, 121–22

Pryce, Nat, 176

Python, 163, 193, 195, 199

Quadrants, testing, 150–51

Query tables, 135–36, 193

checking existence of previously set up data, 135–36

FitNesse SLiM, example of, 193

script tables used to combined with decision tables, 136, 193

Refactoring, 103–18. See also Refactor tests

code, 176

in editing LightStates, 78–90

in LightState enum, 71–78

in Light States test case, 70–90

packages, 71

support code in, 70–90

traffic light calling for, 56, 57

Refactoring in First Crossing test case

adapted validation function, 116

corrected validation function, 114–15

examples, 103

final unit tests for validator, 117

function refactoring into own class, 107

glue, 107–18

new empty validator class, 108

redundant information eliminated from invalid combinations, 104–5

retrofitted unit tests for validator class, 112–13

scenario table references transparent operation, 106–7

scenario table results in collapsible section, 105

scenario table to remove redundant information from invalid combinations, 103

second validation added after light was switched, 114

tests up to failing configuration point, 115

validation function after adding check for blinking second light, 116

validation function after introducing two parameters, 108

validator after moving validation function, 109–10

validator makes parameter to validation function to move method, 109

validator method after rename, 111

validator turned into field within controller class, 110–11

Refactoring in Light States test case, 70–90

all light states covered, 75–78

changed implementation of editor class, 87

code for getAsText method in LightStateEditor, 86

code for LightState enumeration after implementing first method on editor, 85–86

conditional to rescue for red and yellow state, 80

duplication indicates the refactoring potential, 81

editing LightStates, 78–90

extracted body from LightStateEditor as valueFor on LightState class, 87

final example page after, 71

final TrafficLights implementation making use of domain concept of LightState, 90

first and second unit test expressed as data-driven test using JUnit Parameterized runner, 72–74

first code base for new traffic light enum, 72–73

first implementation for LightState transition from red to red and yellow, 73

first implementation of LightStateEditor, 79

first unit test driving domain concept of LightState, 72

iterating over all values in LightState checking for matching description, 82

LightStateEditor code after driving implementation for setAsText, 85

in LightState enum, 71–78

LightState takes String parameter for description in constructor, 81

new unit test class for valueFor method, 88–89

packages, 71

property editor in shortest form, 83

red state makes use of description field, 83

second transition captured, 75

second unit test using data driven format, 79–80

unit test for editor with defaulting behavior unit test removed, 88

unit test for getAsText function in LightStateEditor, 86

unit test for setting value to red, 79

unit tests for editor after finishing implementation for setAsText, 84

Refactoring to Patterns (Kerievsky), 170

Refactor tests, 176–80

extract keyword, 179–80

extract variable, 178–79

Refining examples, 142–46

boundary values, 144–45

domain testing, 143–44

pairwise testing, 145–46

Regression test suite, 147, 148

Robot Framework, 163, 195–99

formats, 140

keywords section used for parking lot calculator, 197–98

keywords used to define test cases, 193, 196

library code, 199

sections, 195–99

Selenium library in, 173

settings used for parking lot calculator, 196

test case section used for parking lot calculator, 196–97

test libraries in, 137

test using keyword template for data-driven tests, 199

Variables section used for parking lot calculator, 198

RowFixture, 135

RSpec book, The (Chelimsky et al.), 187

Ruby, 17, 163, 187, 188

Rule of Three Interpretations, 155, 167. See also Power of Three

Scala, 163

Scenario tables

function of, 59

Given-When-Then-format and, 193

as keyword, 137–38, 184

in refactoring, 103–6

in test cases, 58–59, 103–6

used with script tables, 104, 193

Script tables, 136–37

decision tables combined with query tables, 136, 193

in FIT and FitLibrary, 137

Given-When-Then format and, 140, 193

scenario tables used with, 104, 193

support code and, 194

with whole flow through system, 136

Secret Ninja Cucumber Scrolls, The (de Florinier, Adzic, and de Florinier), 163, 187

Selenium, 18–22, 173–74, 197

headless, 18

library, 22, 173

SetFixture, 135

Setup table, 134, 175, 193

Shell output

from starting FitNesse for the first time, 62

from Valet Parking Automation test case, 19–20, 32, 36

Simple List Invocation Method (SLiM). See also individual tables

decision tables in, 134–35

FitNesse and, 58–59, 163, 191, 192

introduction of, 133

query tables in, 135–36

script tables in, 136–37

support code for tables in, 193–94

Software specifications, 153–59

Power of Three, 153–55

summary, 159

trawl requirements, 158–59

workshops, 155–57

Specification by Example (Adzic), 154–55

Specifications, 93–94

Specification workshops, 48–49

Stable Dependencies Principle, 124

State pattern, 72, 119, 120

State Pattern, 72

State specifications in Light States test case, 61–62

all light states for cars, 62

valid light states for cars, 61

Step definitions

in BDD, 133

Cucumber, 188–89

Short-Term Parking lot test case, 42

in Valet Parking Automation test case, 17–39

SubsetFixture, 135

Successful ATDD, 183–85

Support code

collaboration in, 51

developing, 66–90

for FitNesse SLiM tables, 193–94

format, 139–40

in Light States test case, 66–90

refactoring, 70–90

for setting up Selenium client, 22

in Valet Parking Automation test case, 17–18, 20, 21–22

SWT applications, 152, 183

SWTBot, 152, 183

Tab-ordering, 149

Tabulated formats, 131, 133–37

decision tables, 134–35

query tables, 135–36

script tables, 136–37

script tables with whole flow through system, 136

Tabulated tests in Valet Parking Automation test case, 36–38

examples from workshop filled into table, 37

first test converted to tabulated format, 36

ParkCalcPage class with extended durationMap for Valet Parking tests, 38

shell output with first test in tabulated format, 36–37

Technical Debt, 150

Technical tests, 150

Test, 169–81. See also Test suite

automation, developing, 170–72

code (See Code)

failing, 115–17

gaps, 150–51

intent-revealing, 123, 141

intermodule integration, 150

keyword, extracting, 179–80

language, 124–25, 131, 162

libraries in Robot Framework, 137

listening to, 172–76

parameterized, 59, 73–74, 112, 116

quadrants, 150–52

refactor, 176–80

retrofitted, 91, 112–13, 122, 173, 183

smell, 135

summary, 180–81

tabulated, 36–38

test automation, 170–72

unit, 150, 172

variable, extracting, 178–79

Test automation. See also Test automation code; Test automation tools

architecture, 17

ATDD approach to, 47–48

collaboration in, 47, 164–66

developing, 170–72

listening to tests and, 172–76

pairing on, 164

refactoring in, 176–78

in Valet Parking Automation test case, 17–39

Test automation code. See also Glue code; Support code

flexibility of, 171

format, 131

keywords in, 138

support code and, 70, 139–40

TDD used to implement, 119, 140, 176

testing, 170

Test automation tools

Agile-friendly, 156, 161, 163, 177, 178, 193

ATDD-friendly, 162–66

Cucumber, 187–89

Robot Framework, 193

Test-driven development (TDD). See also Test automation code

vs. ATDD, 118

collaboration in, 51

in domain discovery, 120–21

enum class implemented using, 71–78

Testing Computer Software (Kaner), 143

Test suite

acceptance test, 111–12, 147

benefits of, 122

cutting examples, 146–48

defined, 62

maintenance of, 136

regression, 147, 148

36-hour, 148

Then-keyword, 19, 187

36-hour test suite, 148

Titanic Effect, 150

Traffic Light Software System test cases. See also individual headings

First Crossing test case, 93–118

Getting Started test case, 55–60

Light States test case, 61–91

refactoring, 56, 57

supporting code, 59–60

traffic lights, 55–57

Trawl requirements, 158–59

Twist Framework, 163

Unit test, 150, 172

in Java, example of, 59

retrofitted, 91, 112–13, 122, 173, 183

Unknown-Unknowns Fallacy, 150

Usability tests, 150, 151, 152

User acceptance tests, 150, 151

Valet Parking Automation test case, 17–39. See also Parking lot calculator

initializers, 26–31

mockup for airline parking lot calculator, 25

pairing for first test, 25

summary, 39

tabulated tests, 36–38

Valet Parking Automation test case, first example, 18–25

duration map in, 26–27

empty implementation of parking cost calculation step, 25

empty implementations added to ParkCalcPage class, 24

first Valet Parking test, 18

folder layout, 21

initial ParkCalc class, 22

initial step definitions for, 20

initial wishful implementation of first keyword, 23, 24

shell output from first Valet Parking test, 19–20

shell output from first Valet Parking test with step definitions, 21

support code for setting up Selenium client, 22

Valet Parking Automation test case results, checking, 31–35

check after factoring out two functions for individual steps, 33

final version of ParkCalcPage class for first test, 34–35

final version of steps for first test, 34

final version of Valet Parking steps for first test, 34

initial version of check, 32

shell output from first Valet Parking test, 32

Variables

extracting, 178–79

for parking lot calculator in Robot Framework, 198

Warning configuration, 101

Weinberg, Jerry

Rule of Three interpretations, 167

Titanic Effect, 150

When-keyword, 19, 187

Wiki pages, 58, 66, 191–92

Wiki server, 58, 62

Wiki structure, 191–92

Wiki system, 58

Wishful thinking, 49–50

Workshops, 155–57

frequency and duration, 157

goals of, 156–57

participants, 156

XUnit Test Patterns (Meszaros), 170