What you will learn in BDD in Action, Second Edition

Behavior-Driven Development for the whole software lifecycle

by Jan Molak,John Smart

Read it on liveBook Get the book at manning.com

Chapter by chapter

Chapter 1: Building software that makes a difference

1.1 BDD from 50,000 feet · 1.2 What problems are you trying to solve? · 1.2.1 Building the software right · 1.2.2 Building the right software · 1.2.3 The knowledge constraint: Dealing with uncertainty · 1.3 Is BDD right for your projects? · 1.4 What you will learn in this book · 1.5 Summary

What you learn in chapter 1 →

Chapter 2: Introducing Behavior-Driven Development

2.1 BDD was originally designed to make teaching TDD easier · 2.2 BDD also works well for requirements analysis · 2.3 BDD principles and practices · 2.3.1 Focus on features that deliver business value · 2.3.2 Work together to specify features · 2.3.3 Embrace uncertainty · 2.3.4 Illustrate features with concrete examples · 2.3.5 A Gherkin primer · 2.3.6 Don’t write automated tests; write executable specifications · 2.3.7 These principles also apply to unit tests · 2.3.8 Deliver living documentation · 2.3.9 Use living documentation to support ongoing maintenance work · 2.4 Benefits of BDD · 2.4.1 Reduced waste · 2.4.2 Reduced costs · 2.4.3 Easier and safer changes · 2.4.4 Faster releases · 2.5 Disadvantages and potential challenges of BDD · 2.5.1 BDD requires high business engagement and collaboration · 2.5.2 BDD works best in an Agile or iterative context · 2.5.3 BDD doesn’t work well in a silo · 2.5.4 Poorly written tests can lead to higher test-maintenance costs · 2.6 Summary

What you learn in chapter 2 →

Chapter 3: BDD: The whirlwind tour

3.1 The BDD flow · 3.2 Speculate: Identifying business value and features · 3.2.1 Identifying business objectives · 3.2.2 Discovering capabilities and features · 3.2.3 Describing features · 3.3 Illustrate: Exploring a feature with examples · 3.3.1 Discovering the feature · 3.3.2 Slicing the feature into User Stories · 3.4 Formulate: From examples to executable specifications · 3.5 Automate: From executable specifications to automated tests · 3.5.1 Setting up a project with Maven and Cucumber · 3.5.2 Recording the executable specifications in Cucumber · 3.5.3 Automating the executable specifications · 3.5.4 Implementing the glue code · 3.6 Demonstrate: Tests as living documentation · 3.7 BDD reduces maintenance costs · 3.8 Summary

What you learn in chapter 3 →

Chapter 4: Speculate: From business goals to prioritized features

4.1 The Speculate phase · 4.1.1 Strategic Planning in a BDD project · 4.1.2 Strategic Planning is a continuous activity · 4.1.3 Strategic Planning involves both stakeholders and team members · 4.1.4 Identifying hypotheses and assumptions rather than features · 4.2 Describing business vision and goals · 4.2.1 Vision, goals, capabilities, and features · 4.2.2 What do you want to achieve? Start with a vision · 4.2.3 The vision statement · 4.2.4 Using vision statement templates · 4.2.5 How will it benefit the business? Identify the business goals · 4.2.6 Writing good business goals · 4.2.7 Show me the money: Business goals and revenue · 4.2.8 Popping the “why stack”: Digging out the business goals · 4.3 Impact Mapping · 4.3.1 Identify the pain point · 4.3.2 Define the business goal · 4.3.3 Who will benefit? Defining the actors · 4.3.4 How should their behavior change? Defining the impacts · 4.3.5 What should we do about it? Defining the deliverables · 4.3.6 Reverse Impact Mapping · 4.4 Pirate Canvases · 4.4.1 Pirate Metrics · 4.4.2 From Pirate Metrics to Pirate Canvases · 4.4.3 Discovering what sucks · 4.4.4 Building the Epic Landscape · 4.5 Summary

What you learn in chapter 4 →

Chapter 5: Describing and prioritizing features

5.1 BDD and Product Backlog Refinement · 5.2 What is a feature? · 5.2.1 Features deliver capabilities · 5.2.2 Features can be broken down into more manageable chunks · 5.2.3 A feature can be described by one or more User Stories · 5.2.4 A feature is not a User Story · 5.2.5 Release features and product features · 5.2.6 Not everything fits into a hierarchy · 5.3 Real Options: Don’t make commitments before you have to · 5.3.1 Options have value · 5.3.2 Options expire · 5.3.3 Never commit early unless you know why · 5.4 Deliberate Discovery · 5.5 Release and sprint planning with BDD · 5.6 Summary

What you learn in chapter 5 →

Chapter 6: Illustrating features with examples

6.1 The Three Amigos and other requirements discovery workshops · 6.2 Illustrating features with examples · 6.3 Using tables to describe more complex requirements · 6.4 Example Mapping · 6.4.1 Example Mapping starts with a User Story · 6.4.2 Finding rules and examples · 6.4.3 Discovering new rules · 6.4.4 Surfacing uncertainty · 6.4.5 Facilitating an Example Mapping session · 6.5 Feature Mapping · 6.5.1 Feature Mapping begins with an example · 6.5.2 Examples are broken into steps · 6.5.3 Look for variations and new rules · 6.5.4 Look for alternate flows · 6.5.5 Grouping related flows and recording uncertainty · 6.6 OOPSI · 6.6.1 Outcomes · 6.6.2 Outputs · 6.6.3 Process · 6.6.4 Scenarios · 6.6.5 Inputs · 6.7 Summary

What you learn in chapter 6 →

Chapter 7: From examples to executable specifications

7.1 Turning concrete examples into executable scenarios · 7.2 Writing executable scenarios · 7.2.1 A feature file has a title and a description · 7.2.2 Describing the scenarios · 7.2.3 The Given ... When ... Then structure · 7.2.4 Ands and buts · 7.2.5 Comments · 7.3 Using tables in scenarios · 7.3.1 Using tables in individual steps · 7.3.2 Using tables of examples · 7.3.3 Pending scenarios · 7.4 Organizing your scenarios using feature files and tags · 7.4.1 The scenarios go in a feature file · 7.4.2 A feature file can contain one or more scenarios · 7.4.3 Organizing the feature files · 7.4.4 Using a flat directory structure · 7.4.5 Organizing feature files by stories or product increments · 7.4.6 Organizing feature files by functionality and capability · 7.4.7 Annotating your scenarios with tags · 7.4.8 Provide background and context to avoid duplication · 7.5 Rules and examples · 7.6 Expressive scenarios: Patterns and anti-patterns · 7.6.1 The art of good Gherkin · 7.6.2 What bad Gherkin looks like · 7.6.3 Good scenarios are declarative, not imperative · 7.6.4 Good scenarios do one thing, and one thing well · 7.6.5 Good scenarios have meaningful actors · 7.6.6 Good scenarios focus on the essential and hide the incidental · 7.6.7 Gherkin scenarios are not test scripts · 7.6.8 Good scenarios are independent · 7.7 But where are all the details? · 7.8 Summary

What you learn in chapter 7 →

Chapter 8: From executable specifications to automated acceptance tests

8.1 Introduction to automating scenarios · 8.1.1 Step definitions interpret the steps · 8.2 Setting up your project · 8.2.1 Setting up a Cucumber project in Java or TypeScript · 8.2.2 Organizing a Cucumber project in Java · 8.2.3 Organizing a Cucumber project in TypeScript · 8.3 Running Cucumber scenarios · 8.3.1 Cucumber test runner classes in Java · 8.3.2 Running Cucumber scenarios in JavaScript and TypeScript · 8.4 Writing glue code · 8.4.1 Injecting data with step definition parameters · 8.4.2 Making your Cucumber Expressions more flexible · 8.4.3 Cucumber Expressions and custom parameter types · 8.4.4 Using regular expressions · 8.4.5 Working with lists and data tables · 8.5 Setting up and tearing down with backgrounds and hooks · 8.5.1 Using background steps · 8.5.2 Using hooks · 8.6 Preparing your test environments using hooks · 8.6.1 Using in-memory databases · 8.7 Using virtual test environments · 8.7.1 Using TestContainers to manage Docker containers for your tests · 8.8 Summary

What you learn in chapter 8 →

Chapter 9: Writing solid automated acceptance tests

9.1 Writing industrial-strength acceptance tests · 9.2 Using personas and known entities · 9.2.1 Working with persona in your scenarios · 9.2.2 Storing persona data in HOCON · 9.3 Layers of abstraction · 9.3.1 The Business Rules layer describes the expected outcomes · 9.3.2 The Business Flow layer describes the user’s journey · 9.3.3 Business tasks interact with the application or with other tasks · 9.3.4 The Technical layer interacts with the system · 9.4 Summary

What you learn in chapter 9 →

Chapter 10: Automating acceptance criteria for the UI layer

10.1 When and how should you test the UI? · 10.2 Where does UI testing fit in your test automation strategy? · 10.2.1 Which scenarios should be implemented as UI tests? · 10.2.2 Illustrating user journeys · 10.2.3 Illustrating business logic in the user interface · 10.2.4 Documenting and verifying screen-specific business logic · 10.2.5 Showing how information is rendered in the user interface · 10.2.6 Automating web-based acceptance criteria using Selenium WebDriver · 10.2.7 Getting started with WebDriver in Java · 10.2.8 Setting up a WebDriver driver · 10.2.9 Integrating WebDriver with Cucumber · 10.2.10 Sharing WebDriver instances between step definition classes · 10.2.11 Interacting with the web page · 10.2.12 How to locate elements on a page · 10.2.13 Interacting with web elements · 10.2.14 Working with modern UI library components · 10.2.15 Working with asynchronous pages and testing AJAX applications · 10.3 Test-friendly web applications · 10.4 Next steps · 10.5 Summary

What you learn in chapter 10 →

Chapter 11: Test automation design patterns for the UI layer

11.1 The limitations of unstructured test scripts · 11.2 Separating location logic from test logic · 11.3 Introducing the Page Objects pattern · 11.3.1 Page Objects are responsible for locating elements on a page · 11.3.2 Page Objects represent objects on a page, not an entire page · 11.3.3 Page Objects tell you about the state of a page · 11.3.4 Page Objects perform business tasks or simulate user behavior · 11.3.5 Page Objects present state in business terms · 11.3.6 Page Objects hide wait conditions and other incidental implementation details · 11.3.7 Page Objects do not contain assertions · 11.3.8 WebDriver Page Factories and the @FindBy annotation · 11.3.9 Finding collections · 11.3.10 Page Objects in Serenity BDD · 11.4 Going beyond Page Objects · 11.4.1 Action classes · 11.4.2 Query classes · 11.4.3 DSL layers and builders · 11.5 Summary

What you learn in chapter 11 →

Chapter 12: Scalable test automation with the Screenplay Pattern

12.1 What is the Screenplay Pattern, and why do we need it? · 12.2 Screenplay fundamentals · 12.3 What is an actor? · 12.4 Actors perform tasks · 12.5 Interactions model how actors interact with the system · 12.5.1 Actors can perform multiple interactions · 12.5.2 Interactions are objects, not methods · 12.5.3 Interactions can perform waits as well as actions · 12.5.4 Interactions can also interact with REST APIs · 12.6 Abilities are how actors interact with the system · 12.7 Writing our own interaction classes · 12.8 Questions allow an actor to query the state of the system · 12.8.1 Questions query the state of the system · 12.8.2 Domain-specific Question classes make our code more readable · 12.8.3 Actors can use questions to make assertions · 12.9 Tasks model higher-level business actions · 12.9.1 Simple tasks improve readability · 12.9.2 More complex tasks enhance reusability · 12.10 Screenplay and Cucumber · 12.10.1 Actors and casts · 12.10.2 The Screenplay stage · 12.10.3 Defining a custom parameter type for actors · 12.10.4 Defining persona in enum values · 12.10.5 Screenplay assertions in Cucumber · 12.11 Summary

What you learn in chapter 12 →

Chapter 13: BDD and executable specifications for microservices and APIs

13.1 APIs and how to test them · 13.2 Defining a feature using a web UI and a microservice · 13.2.1 Understanding the requirements · 13.2.2 From requirements to executable specifications · 13.3 Automating acceptance tests for microservices · 13.4 The microservice architecture under test · 13.4.1 Preparing the test data · 13.4.2 Performing a POST query: Registering a Frequent Flyer member · 13.4.3 Querying JSON responses with JSONPath · 13.4.4 Performing a GET query: Confirming the frequent flyer address · 13.4.5 Partial JSON Responses: Checking the new Frequent Flyer account details · 13.4.6 Performing a DELETE query: Cleaning up afterward · 13.5 Automating more granular scenarios and interacting with external services · 13.6 Testing the APIs or testing with the APIs · 13.7 Summary

What you learn in chapter 13 →

Chapter 14: Executable specifications for existing systems with Serenity/JS

14.1 Navigating an uncharted territory with Journey Mapping · 14.1.1 Determine actors and goals to understand the business context · 14.1.2 Determine what workflows support the goals of interest · 14.1.3 Associate workflows with features · 14.1.4 Establish a steel thread of scenarios that demonstrate the features · 14.1.5 Determine verifiable consequences of each scenario · 14.1.6 Using task analysis to understand the steps of each scenario · 14.2 Designing scalable test automation systems · 14.2.1 Using layered architecture to design scalable test automation systems · 14.2.2 Using actors to link the layers of a test automation system · 14.2.3 Using actors to describe personas · 14.3 Capturing business context in the Specification layer · 14.4 Summary

What you learn in chapter 14 →

Chapter 15: Portable test automation with Serenity/JS

15.1 Designing the Domain layer of a test automation system · 15.1.1 Modeling business domain tasks · 15.1.2 Implementing business domain tasks · 15.1.3 Composing interactions into tasks · 15.1.4 Using an outside-in approach to enable task substitution · 15.1.5 Leveraging non-UI interactions with blended testing · 15.1.6 Using tasks as a mechanism for code reuse · 15.1.7 Implementing verification tasks · 15.2 Designing a portable Integration layer · 15.2.1 Writing portable tests for the web interfaces · 15.2.2 Identifying page elements · 15.2.3 Implementing Lean Page Objects · 15.2.4 Implementing Companion Page Objects · 15.2.5 Implementing portable interactions with Page Elements · 15.2.6 Using Page Element Query Language to describe complex UI widgets · 15.2.7 Configuring web integration tools · 15.2.8 Sharing test code across projects and teams · 15.3 Summary

What you learn in chapter 15 →

Chapter 16: Living documentation and release evidence

16.1 Living documentation: A high-level view · 16.2 Reporting on feature readiness and feature coverage · 16.2.1 Feature readiness: What features are ready to deliver · 16.2.2 Feature coverage: What requirements have been built · 16.3 Integrating a digital product backlog · 16.4 Leveraging product backlog tools for better collaboration · 16.5 Organizing the living documentation · 16.5.1 Organizing living documentation by high-level requirements · 16.5.2 Organizing living documentation using tags · 16.5.3 Living documentation for release reporting · 16.5.4 Low-level living documentation · 16.5.5 Unit tests as living documentation · 16.6 Living documentation for legacy applications · 16.7 Summary

What you learn in chapter 16 →

Concepts explained in this book

behavior-driven developmentBDD is a collection of collaborative practices for discovering business needs and obtaining automated feedback that implemented features meet agreed expectations.
acceptance criteriaAn acceptance criterion is a condition that a feature or user story must satisfy to be accepted as complete.
featureA software feature is a distinct capability or behavior provided by a software system.
scenario keywordThe Scenario (or Example) keyword is a Cucumber syntax keyword that introduces an executable behavior scenario.
business goalA business outcome is a measurable result that an organization seeks to achieve through a project or solution.
executable specificationAn executable specification is a business-readable description of expected software behavior that can be directly transformed into or executed as an automated check.
scenarioA scenario is a concrete description of system behavior under specified conditions, typically expressing an example that can be evaluated or automated.
acceptance testingAn acceptance test verifies that software satisfies agreed behavioral and business requirements.
user storyA user story is a concise requirement describing a capability from the perspective of a user or other stakeholder.
screenplay patternScreenplay is an actor-centric test-automation pattern that structures behavior around actors performing reusable tasks through abilities and interactions while answering questions about system state.
living documentationLiving documentation is documentation generated from executable specifications so that it reflects and verifies the implemented behavior of software features.
business ruleA business rule is a constraint, policy, or decision rule that governs how a business process or system should behave.
page objectA page object is a test automation abstraction that encapsulates a web page's structure and interaction details while exposing readable operations and state.
actorAn actor is a person, system, or process that interacts with the system under test and pursues goals through activities and abilities.
shared understandingA common and sufficiently detailed interpretation of requirements, behavior, and value held by the people collaborating on a product.
taskA Screenplay task is a reusable actor-behavior abstraction representing a meaningful activity, composed from interactions or other tasks.
business valueBusiness value is the measurable benefit that a software product or capability provides to an organization.
step definitionA step definition is an executable mapping that connects a human-readable behavior-specification step to code that performs or verifies the corresponding application interaction.
requirements discoveryA requirements discovery workshop is a collaborative meeting in which stakeholders and delivery-team members elicit, clarify, and explore software requirements.
requirementsA requirement is a stated capability, condition, or constraint that a software system is expected to satisfy.
unit testUnit testing is the evaluation of individual software components in isolation from the rest of the application.
feature fileA feature file is a plain-text Gherkin document that describes one software feature and its scenarios.
capabilityA capability is an ability that enables users or stakeholders to achieve a goal or fulfill a task independently of a particular implementation.
WebElementA web element is an individual element in a web document that can be located and interacted with through browser automation.
pirate canvasA Pirate Canvas is a planning framework that applies Pirate Metrics to analyze ecosystem growth constraints, opportunities, assumptions, and potential products or services.
outside-in developmentOutside-in development is an implementation approach that starts with externally visible behavior or acceptance outcomes and progressively develops the internal components and behavior needed to support them.
glue codeGlue code is integration code that connects executable behavior specifications or test steps to application code and services.
retentionA retention metric measures the extent to which users or customers continue returning to or using a product, service, or program.
business taskA business task is a cohesive user-oriented activity that contributes to a business goal and can be composed into a user journey.
web application testingA web test verifies the behavior of a web application through browser-based or web-level interactions.
acquisition metricAn acquisition metric measures how effectively a product or service attracts new users or customers.
activation metricAn activation metric measures the extent to which newly acquired users begin engaging with and recognizing value in a product, service, or program.
SeleniumThe WebDriver API is the programmatic interface for controlling browser sessions and interacting with web pages through WebDriver.
specification by exampleExample-driven development is a software development approach that uses concrete examples to guide understanding, specification, and implementation.
Given/When/Then formatGiven-When-Then notation is a structured scenario format for expressing preconditions, an action or event, and the expected outcome.
evaluation suiteA test suite is a collection of tests organized to evaluate software behavior against defined expectations.
XPathAn XPath expression is a path query that selects nodes in a structured document such as an HTML or XML document.
deliverableA deliverable is an application capability or other outcome produced by a delivery team to support a desired behavior change.
journey mapA Journey Map is a visual planning artifact that organizes actors, goals, workflows, scenarios, outcomes, and business rules for a system.
feature mappingFeature mapping is a collaborative requirements technique for exploring and organizing a software feature's behavior, flows, variations, and examples.
CucumberCucumber is a tool that executes behavior specifications written in a human-readable, structured format as automated tests.
cucumber expressionA Cucumber expression is a pattern notation for matching Gherkin steps and converting captured text into parameters for step definitions.
product visionA project vision statement is a concise declaration of the intended value and measurable outcome of a project.
GherkinGherkin is a human-readable structured language for expressing software behavior specifications as features and scenarios.
Page Element Query LanguageThe Page Element Query Language is Serenity/JS's portable query syntax for locating page elements and deriving information from them.
database tableA table is a structured arrangement of related values in rows and columns that can represent complex scenario data.
pirate metricsPirate metrics, also called AARRR, are a startup and product measurement framework organized around acquisition, activation, retention, revenue, and referral.
workflowA business process is an organized sequence of activities that produces a business result.
PageElementPageElement is a Serenity/JS web API abstraction representing an element located within a web page and supporting composable interactions and questions.
test-driven developmentTest-driven development is a software development technique in which automated tests are created before the implementation they verify.
callbackA hook is a framework callback method that runs before or after a specified software execution event.
automation solutionA test automation system is a supporting software system that integrates automated tests, execution frameworks, libraries, and glue code to verify and document the behavior of another system.
stepA step is an individual Gherkin statement representing a precondition, action, or expected outcome in a scenario.
real optionsReal options is a decision-making principle that preserves the ability to defer or abandon a commitment until better information is available, while recognizing that options have value and expire.
password-strength algorithmA password-strength algorithm is an algorithm that evaluates the resistance of a password to guessing or cracking.
referralReferral is the metric measuring how effectively users introduce other people to an organization's products or services.
returnReturn is a Pirate Metric measuring the financial or broader ecosystem benefits generated by customers and their activity.
impact mappingAn impact map is an iterative visual document representing relationships and assumptions between business goals and the capabilities or deliverables intended to support them.
epicAn epic is a high-level software or business deliverable representing a broad capability needed to address a business problem or achieve a goal.
customer journeyA user journey is the sequence of interactions and experiences through which a user pursues a goal with a product or service.
abstractionAbstraction is the software design practice of separating an interface or high-level behavior from the details of its implementation.
interactionA web interaction is a Screenplay-compatible operation that performs an action through a web interface without exposing the underlying browser-automation tool.
feedbackFeedback is information about observed results or understanding that guides subsequent decisions, actions, or improvements.
component testingA component test evaluates an individual software component or UI component in isolation from parts of the wider system.
epic landscapeAn Epic Landscape is a breadth-first view of the epics and capabilities needed to address business problems and achieve business goals.
Example MappingExample Mapping is a collaborative BDD technique for exploring rules, examples, and questions about a requirement.
JSON path languageA JSONPath expression is a query expression for selecting or evaluating values within JSON data.
data attributeAn HTML data attribute is a custom data-* attribute for storing additional information on a standard HTML element.
HTML id and name attributesHTML id and name attributes are element attributes that provide identifying or form-related names in an HTML document.
link text selectorA link text selector locates a hyperlink by matching the text displayed for that link.
nested lookupA nested lookup locates a descendant element by searching from an already located parent element.
CSS selectorA CSS selector is a pattern for selecting elements in a web document based on element names, classes, attributes, relationships, and other criteria.
happy pathA happy path scenario is a scenario in which valid inputs and expected conditions lead to a successful outcome without exceptional behavior.
REST AssuredREST Assured is a Java library for testing and validating REST-based HTTP APIs through programmatic requests and response assertions.
personaA persona is a detailed representation of a typical user, including characteristics such as goals, abilities, background, and motivations.
notepadA notepad is an actor-associated store for retaining static or dynamically resolved information during Screenplay interactions.
custom parameter typeA custom parameter type is a user-defined Cucumber parameter type that recognizes text in a step and converts it into a specified object or value.
counterexampleA counterexample is a concrete case showing where a proposed rule or expected behavior does not apply or produces an incorrect result.
getText methodThe getText method is a WebDriver operation that retrieves the text content of a web element.
pirate metricA pirate metric is an individual stage or dimension in the Pirate Metrics framework.
taggingA tag is a label attached to a requirement or other item to support classification, organization, and reporting.
last responsible momentThe last responsible moment is the latest point at which a decision can be made without jeopardizing the ability to deliver the required outcome.
Serenity/JSSerenity/JS is a JavaScript and TypeScript acceptance-testing framework for writing, executing, and reporting automated tests.
abilityAn ability is a Screenplay capability that enables an actor to interact with a system through a particular mechanism, such as a browser or API.
assumptionAn assumption is an unverified belief about goals, actors, behavior, or solution effects that underlies a project plan.
questionA web question is a Screenplay-compatible query that retrieves information about the state of a system through its web interface.
blended testingBlended testing is a testing approach that combines interchangeable implementations of actor-facing tasks across different levels of abstraction.
reuseCode reuse is the practice of applying existing software code in multiple contexts instead of duplicating its implementation.
Serenity BDDSerenity BDD is a test automation and reporting framework that supports behavior-driven development specifications.
test dataTest data is data prepared or managed to establish conditions for executing and verifying software tests.
deliberate discoveryDeliberate Discovery is an approach for generating information through investigation and experimentation so that design and implementation decisions can be made deliberately.
attemptsToattemptsTo is a Screenplay API method that directs an actor to perform a sequence of interactions.
why stackA why stack is an iterative questioning technique that traces a requested feature through successive reasons until it reaches an underlying business goal or value.
testAn automated test is a software-based check that runs without manual execution to determine whether behavior meets specified expectations.
WaitUntilWaitUntil is a Serenity BDD Screenplay interaction that pauses execution until a specified condition is satisfied.
collaborative conversationsCollaborative conversations are structured discussions among business, development, and testing participants to clarify goals, outcomes, assumptions, and expected behavior.
user-interaction testingA UI test verifies software behavior through its user interface rather than through internal program interfaces.
QuestionAdapterA QuestionAdapter is a proxy that presents static, dynamic, or asynchronously resolved data through a consistent Screenplay API.
domain layerA domain layer is the architectural layer of a test automation system that models the activities required to complete specified business workflows.
waitWait is a Serenity BDD waiting utility that pauses execution until an arbitrary function has completed or a supplied condition is met.
unhappy pathAn unhappy path scenario is a scenario in which invalid inputs, exceptional conditions, or failures produce behavior other than the normal successful outcome.
uncertaintyUncertainty is incomplete or evolving knowledge about what a software system should accomplish and how it should be built.
product backlogA product backlog is an ordered collection of proposed work items, such as features, requirements, and improvements, for a product; it may be maintained electronically.
business flow layerA business flow layer is a high-level test-code layer that expresses user tasks and system workflows in business terms while delegating application interactions to lower-level components.
castThe Cast interface is the Serenity/JS contract responsible for providing actors configured with their abilities and initial state.
@serenity-js/web@serenity-js/web is the Serenity/JS module that provides Screenplay-compatible abstractions for interacting with and querying web interfaces.
Question.fromObject APIQuestion.fromObject is a Serenity/JS API operation that combines static, dynamic, or partially dynamic object properties into a QuestionAdapter.
TestcontainersTestcontainers is an open-source library that provides lightweight, disposable containerized dependencies for automated tests.
element selectorAn element selector is a locator that identifies a web element in a document or user interface.
Ensure.thatEnsure.that is a Serenity/JS interaction that verifies an expectation about a value or state.
expectationAn expectation is a declarative condition that evaluates whether an observed value or state satisfies a specified criterion.
@serenity-js/assertions@serenity-js/assertions is a Serenity/JS module providing assertions and expectations for verifying application state in automated tests.
synchronization statementA synchronization statement coordinates test execution with an asynchronous system condition or elapsed duration.
verification taskA verification task is a reusable test activity that checks whether an application state or outcome satisfies business-specific expectations.
strategic planningStrategic planning is a recurring process for turning strategic business opportunities and challenges into a prioritized set of deliverable software features.
regular expressionA regular expression is a pattern notation for matching and extracting text according to specified character and repetition rules.
specification layerA specification layer is the architectural layer of a test automation system that expresses important workflows, business rules, and usage examples in stakeholder-readable form.
multi-tier applicationLayered architecture is a software architecture pattern that organizes responsibilities into layers with controlled dependencies between them.
continuous integrationContinuous integration is a development practice in which changes are integrated into a shared codebase frequently and validated automatically.
Cucumber EventListenerA Cucumber EventListener is a plugin interface whose implementation registers handlers for events published during a Cucumber test run.
tag expressionA Cucumber tag expression is a boolean expression used to select scenarios or features based on their tags.
Companion Page ObjectsCompanion Page Objects are reusable Screenplay-style page-object abstractions published alongside UI components to encapsulate interactions and enable test-code reuse.
structured conversationA structured conversation is a deliberately guided discussion that establishes a shared understanding of business rules, examples, and expected behavior.
interaction classAn interaction class is a reusable test-automation component that represents an actor's interaction with an application through a particular technology.
measurable business goalA measurable business goal is a desired organizational outcome stated with observable quantities or time conditions that allow achievement to be assessed.
backlog refinement meetingBacklog refinement is the activity of clarifying, splitting, estimating, and reordering upcoming backlog items.
PageElementsPageElements is a Serenity/JS abstraction representing a collection of web elements and exposing queries over that collection.
big-picture scenarioA big-picture scenario is a high-level scenario that represents an overall business flow while abstracting away detailed inputs and implementation steps.
integration layerAn integration layer is the architectural layer of a test automation system that translates domain activities into low-level interactions with external system interfaces and manages their clients.
test runnerA test runner is a tool or framework component that discovers, schedules, and executes automated tests.
locator strategyA locator strategy is an approach for identifying target elements in a web document so automated tests can interact with them.
soap opera personaA soap opera persona is a lightweight user representation introduced incrementally as stories and scenarios reveal more about the character.
speculate phaseThe Speculate phase is the initial BDD phase in which teams hypothesize features that could help achieve organizational goals.
examples tableAn example table is a tabular Gherkin data structure whose rows supply parameter values for repeated scenario executions.
steel threadA steel thread is a minimal, end-to-end implementation path that exercises the essential workflow of a system before broader functionality is developed.
scenario outlineA scenario outline is a Gherkin construct that defines a parameterized scenario whose placeholders are replaced with values from an examples table for repeated execution.
microservice architectureMicroservice architecture is an application architecture in which independently deployable services implement separate business capabilities and communicate through defined interfaces.
MavenMaven is a build automation and project management tool widely used for Java projects.
organizational agilityAn Agile organization is an organization that structures its work and decision-making around iterative delivery, adaptation, and feedback.
documentationTechnical documentation is information describing software behavior, implementation intent, interfaces, or operation for technical practitioners.
customer journey mappingJourney mapping is a collaborative technique for representing how actors use a system to achieve goals and for identifying important scenarios and priorities.
FluentWaitA fluent wait is a configurable synchronization technique that repeatedly checks a condition at specified intervals while handling selected waiting behavior.
portabilityTest portability is the property of test automation code that allows it to operate across different contexts or integration tools with limited change.
declarative programmingDeclarative programming style expresses desired results or relationships without specifying every execution step.
imperative programmingImperative programming style expresses computation as ordered commands that change program state.
parameter type annotationThe ParameterType annotation is a Cucumber annotation that identifies a method defining a custom parameter type.
shared business languageA shared business language is a common vocabulary and expression style that lets business and technical team members describe software behavior and needs consistently.
domain conceptA business domain is the area of organizational activity, knowledge, and processes that a software solution addresses.
business problemA business need is a required improvement or capability arising from an organization's goals or difficulties.
ExpectedConditionsExpectedConditions is a Selenium utility class providing predefined predicates for common browser-state conditions.
system-level verificationA system-level test evaluates behavior with the system assembled at a level that represents a complete or substantially complete deployed system.

These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.