anchor.diff:  
   The code listed above certainly reads cleanly, but it may leave you wondering how it actually works under the hood. Let’s see how it all fits together.
   
  -==== Journey Pattern tests runs like any other Serenity test ====
  +=== Journey Pattern tests runs like any other Serenity test ===
   
   At the time of writing, the Serenity Journey pattern integrates with both JUnit and Cucumber. For example, in JUnit, you use the SerenityRunner JUnit runner, as for any other Serenity JUnit tests. The full source code of the test we saw earlier is shown here:
   
  
positive.code: 
  It is quite frequent to reuse existing tasks to build up more sophisticated business tasks in this way.
  
  ===== Actors can ask questions about the state of the application =====
  
  A typical automated acceptance test has three parts:
  1. Set up some test data and/or get the application into a known state
  
negative.code: 
  Each of the actor’s abilities is represented by an Ability class (in this case, `BrowseTheWeb`) which keeps track of the things the actor needs to perform this ability (for example, the `WebDriver` instance used to interact with the browser). Keeping the things an actor can do (browse the web, invoke a web service...) separate from the actor makes it easier to extend the actor’s abilities. For example, to add a new custom ability, you just need to implement a new `Ability` class.
  
  === Actors perform tasks ===
  
  An actor needs to perform a number of tasks to achieve a business goal. A fairly typical example of a task is “adding a todo item”, which we could write as follows:
  
  