Release
Serenity 1.1 is out!
Fully-integrated feature coverage reporting and the ability to mix manual and automated tests in one report. (27 Jul 2015)
Official Serenity BDD Blog
Automated Acceptance Testing
for BDD, Cucumber & Selenium
News, tutorials, release notes and field-tested tips for teams practising BDD and ATDD with Serenity, JBehave, Cucumber, JUnit and JIRA.
Followed by testers & developers shipping living documentation since Thucydides 0.9.x.
From the blog· 27 Jul 2015
“Serenity 1.1 is out — with fully-integrated feature coverage reporting.”
BDDATDDSeleniumJUnitCucumberJBehaveJenkinsJIRA
See Serenity BDD in action
Walk through feature coverage reports, manual test flagging and the living documentation that Serenity generates from your acceptance tests.
Serenity 1.1 — fully-integrated feature coverage reporting
From announcement to working test
Three common paths readers take on this blog — pick the one that matches your team today.
Step 01 · News
Read the latest announcements
Get the short version of every Serenity release and what it changes in practice for your test reports.
Step 02 · Tutorials
Follow a working tutorial
Walk through Cucumber feature file organisation, JIRA integration and writing BDD-style acceptance criteria.
Step 03 · Tips & Releases
Apply tips to your current build
Try implicit waits, batch strategy and parallel testing techniques on your existing Serenity or Thucydides project.
Plain reports vs. Serenity living documentation
Drag the divider to compare a typical JUnit output with what Serenity BDD generates from the same suite.
BeforeA stack trace, a red bar and a folder of screenshots nobody opens.
AfterRequirements, features and steps reported in terms the whole team can read.
Recent articles on the blog
Release announcements, tutorials and tips from the Serenity BDD community archive.
Tutorial
Customizing Cucumber Feature File organization
A practical guide to organising Cucumber features so Serenity reports stay readable as your suite grows. (9 Apr 2015)
Release
Serenity 1.0.42 and the new Timeout API
Notes on the 1.0.42 release and a redesigned timeout API for clearer implicit waits and explicit waits. (20 Mar 2015)
Living documentation sits at the heart of modern acceptance testing, turning executed scenarios into searchable, readable evidence of what a system actually does. When teams adopt behaviour-driven development practices, the reports that fall out of the build become a shared source of truth for testers, developers, and product owners alike, replacing stale specifications with artefacts that evolve alongside the code.
Good acceptance test suites mirror the way people describe features in conversation, which is why frameworks that encourage narrative, business-readable steps tend to age well. Writing scenarios in plain language first and then binding them to page-level actions keeps the conversation focused on outcomes while still allowing the technical layers to be refined as the application grows and changes.
Page objects remain a quiet superpower behind maintainable browser-based tests, giving teams a single place to encode the structure of a screen and the interactions it supports. By treating locators, waits, and high-level actions as named members of a class, suites become easier to read, faster to update, and more resilient to the small interface changes that would otherwise ripple through every scenario.
Integrating acceptance tests with issue trackers turns passing and failing scenarios into something the wider organisation can react to. Linking a test outcome to its originating requirement or ticket gives everyone, from engineers to stakeholders, a way to see progress and risk in the same view, which encourages honest conversations about scope, coverage, and the meaning of done.
Configuration is often the difference between a demo and a dependable pipeline, and thoughtful defaults go a long way toward keeping tests portable across environments. Treating capabilities, timeouts, and base URLs as properties that can be overridden per run makes it easier to share a single suite between local development, continuous integration, and exploratory sessions without rewriting the underlying steps.
Screenshots and step-level evidence give failing tests a voice, helping reviewers understand not just that something broke but how it broke. Captured automatically and woven into the report, this trail of context shortens debugging cycles, supports retrospectives, and gradually builds a visual history of the application that is just as valuable as the green builds themselves.