Role Objects in Acceptance Tests

I’m a big fan of utilizing page objects in acceptance tests. Page objects are used to model sections of your UI and minimize duplication within your specs. They also codify the actions which can be taken on specific pages. This minimizes how many files must be updated by encapsulating the details of how and where actions occur. All of us would agree that these are great things to have in your tests and code, but many of us are missing another hiding spot of behavior.

In Comes the Role Object

A role object, in this context, is an object that takes on the part of a system user. These objects maybe an admin, a buyer, a seller, or any other user of your system. Just as page objects codify the actions that are taken on a page, role objects codify the actions which a specific role can perform.

  buyer.login
  seller.login

  seller.list_item(@item)

  buyer.purchase(@item)

Through these abstractions a nice testing api emerges and the details of where and how are no longer a concern. In order to find out what actions are available to a buyer there is only one place to look. How about a seller? Still one place to look.

The power that you gain is not only in refactoring and organization, but you are now easily allowed to utilize polymorphism in your step definitions. Setting up a context in given steps allows When steps to no longer care which role is performing the action. In addition, the When step now no longer needs to care about the differences between how each role performs the action.

  Given "I am a buyer" do
    @user = Buyer.new
  end

  Given "I am a seller" do
    @user = Seller.new
  end

  When "I login" do
    @user.login
  end

Let’s use the power of OO Design in our testing. If duplication is found between these role objects there are many OO design techniques which can be employed to fix that issue. Code is there to communicate and tell a story. Tests are used to communicate and tell a story. So let’s make sure that we are clear and concise when telling that story. Don’t let yourself get hung up in gritty details and duplication. You may also find that roles pop out in your head and help you think of new actions. Maybe you create a PowerUser role that utlizes keyboard shortcuts instead of clicking links. The only thing that needs to change in your scenario is the Given step and you have multiple paths through your UI.

DISCLAIMER:

As with all forms of abstraction you have to live with the levels you create.

The Past

• Testing Named Agents 03 Feb 2017
• Two Duplication Refactorings in Elixir 18 Jan 2017
• B is for BigDecimal 24 Sep 2014
• A is for Abbrev 02 Sep 2014
• Missed Chances 15 Aug 2014
• Style Guides are Failures 15 Jun 2014
• What is BDD anyway? 15 Apr 2014
• An Agile Contract 31 Mar 2014
• What Do I Want 23 Mar 2014
• Just the Tip 16 Mar 2014
• Important Partnerships 11 Mar 2014
• Lost in Translation 03 Mar 2014
• Story Splitting Revisited 23 Feb 2014
• Let your yes be yes and your no be no 16 Feb 2014
• Lethal Injection 09 Feb 2014
• Smaller is Better 02 Feb 2014
• A Second Time 26 Jan 2014
• Introspective 20 Jan 2014
• Self Reflection for the Win 06 Dec 2013
• Why? Why? Why? 30 Sep 2013
• A New Gig 18 Sep 2013
• Exceptional Comments 15 Jun 2013
• Role Objects in Acceptance Tests 30 Apr 2013
• Open Closed Ruby Woes 28 Apr 2013
• Write Something 12 Apr 2013
• A Great Cast of Characters 06 Mar 2012
• When is the Release Party? 19 Aug 2011
• Single Responsibilty, How Did I Forget You 12 Apr 2011
• Change Classes not Styles 05 Nov 2010
• My MongoDB Cookbook Recipe 20 Jul 2010
• Agile Says What? 05 Nov 2009
• Inject & Me - BFFs 07 Sep 2008