anchor.diff:  
   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 ====
  +=== 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:
   
  
positive.code: 
  As you might expect, this code checks a value retrieved from the application (the items displayed on the screen) against an expected value (described by a Hamcrest expression). However, rather than passing an actual value, we pass a Question object. The role of a Question object is to answer a precise question about the state of the application, from the point of view of the actor, and typically using the abilities of the actor to do so.
  
  ===== Actors use their abilities to interact with the system =====
  
  Let’s see this principle in action in another test. The Todo application has a counter in the bottom left hand corner indicating the remaining number of items (see <<fig-journey-remaining-count>>).
  
  
negative.code: 
  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 ===
  
  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:
  
  