Serenity - that feeling you get when you know you can trust your tests

Serenity (previously known as 'Thucydides') is a library designed to make writing automated acceptance tests easier, and more fun.

What does it do?

Serenity helps structure your automated acceptance tests in order to make them easier to understand and maintain, and provides great reporting capabilties on top of tools like JBehave, Cucumber or JUnit. It also provides tight integration with WebDriver, to make automated web testing easier and more efficient.

Serenity works in two ways:

• It instruments your test code and reports on the steps that your tests execute to achieve their goals, and stores the test results in a standardized format;
• It aggregates these test results into clear and meaningful reports, that reflect not only the outcomes of your tests, but also the status of your project. For example, you can get Serenity to report on what requirements, features or stories you have implemented, and how well (or not) they were tested.

History - Serenity and Thucydides

Serenity was originally called Thucydides, and the package structure still reflects this history. Thucydides is discussed at length in the BDD in Action under the name Thucydides - everything discussed in "BDD in Action" is directly applicable for Serenity except for the artifact names.

Thucydides was renamed Serenity in November 2014, and moving forward, all new work will be done on Serenity. The artifact names reflect this change, e.g.

• net.thucydides:thucydides-code becomes net.serenity:core
• net.thucydides:thucydides-junit becomes net.serenity:serenity-junit
• net.thucydides:thucydides-jbehave becomes net.serenity:serenity-jbehave
• net.thucydides:thucydides-cucumber becomes net.serenity:serenity-cucumber

and so on.

Version number format

Serenity uses a three-digit version number notation, with the following meaning:

 <major>.<minor>.<build>

The first and second digits are for more significant updates, including new features or important bug fixes. The third is updated automatically for every new release, and is generated by the build process.

Commit message conventions

Commit messages are used to generate the release notes for each release. To do this, we loosely follow the AngularJS commit conventions: for commit messages to appear in the release notes, the title line needs to respect the following format:

  <type>: <message>

where is one of the following:

• feat: A new feature
• fix: A bug fix
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• refactor: A code change that neither fixes a bug or adds a feature
• perf: A code change that improves performance
• test: Adding missing tests
• chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

Also commits can consists of several lines - to include some additional information in relase notes. For example:

feat: A new feature to make something better
now it will be available to call api.function() with additional parameters like api.function(Integer)

it will be included in release notes as:

• feat: A new feature to make something better

  now it will be available to call api.function() with additional parameters like api.function(Integer)

Please take a look at release notes to find some more examples of mutiline commits.

For more information, read the Contributing guide for this repo.

Starting from version 1.1.26, any commits without one of these prefixes will not appear in the release notes.

Licensing

This distribution, as a whole, is licensed under the terms of the Apache License, Version 2.0