0

I have a working table:

#some javascript stuff
!define or { || }

#my stuff
!define headers { !-Authorization: Basic YWRtaW46cGFzc3dvcmQ=
Accept: application/json -! }

|Table:smartrics.rest.fitnesse.fixture.RestFixture|http://admin:password@localhost:5984/|
|setHeaders|${headers} |
|DELETE    |/q-couch | | | jsonbody.ok ${or} jsonbody.error=="not_found"  |

I now want to re-factor to make reusable component, and more readable test. I tried this:

#what I hoped would be a reusable component.
|scenario|deletedb|name|
|Table:smartrics.rest.fitnesse.fixture.RestFixture|http://admin:password@localhost:5984/|
|setHeaders|${headers} |
|DELETE|/@dbName | | |jsonbody.ok ${or} jsonbody.error=="not_found"  |   

#A more readable test
|Script|
|deletedb|q-couch|

When I press test I get The instance scriptTableActor. does not exist on every line in the scenario, within the script.

Is what I am doing valid? What am I doing wrong?

ctrl-alt-delor
  • 7,506
  • 5
  • 40
  • 52

1 Answers1

3

Why the error

The scriptTableActor. error occurs since you do not give a reference to any fixture in your script table header. Snipped from ScriptTable guide:

The first row is simply the word "Script" followed by the name and constructor arguments of the fixture (known as the "actor") that will be used by the rest of the table. If there is no actor specified then the previous script table's actor on this test page will be used.

The RestFixture has a special fixture for script tables, so your first row should be defined as:

|Script|RestScriptFixture|http://admin:password@localhost:5984/|

Reusable RestFixture components

I have used a structure of scenarios (defined in a ScenarioLibrary) and building blocks that we include to get reusable components. This strategy could also be used with other fixtures than RestFixture.

In your case I would had defined following scenarios

!|Scenario|When a |http_verb |is sent to |service |with headers set to |headers|
|setHeaders|@headers|
|@http_verb|@service|

!|Scenario|the response should contain |element |equal to |value |or |second_element |equal to |second_value|
|check|js|(response.jsonbody.hasOwnProperty('@element') && response.jsonbody.@element.toString()==@value)!-||-!(response.jsonbody.hasOwnProperty('@second_element') && response.jsonbody.@second_element.toString()==@second_value)|true|

The second scenario is a bit hefty, so a explanation could be in order. Since I do not know if ok and error always are returned in your response, first it checks whether the element exists or not with response.jsonbody.hasOwnProperty('@element') and then it checks if it has the correct value with response.jsonbody.@element.toString()==@value). I have escaped the or operator || with !--!.

The building block wiki would look like following:

|Script|RestScriptFixture|${server}|
|When a |delete |is sent to |${service} |with headers set to |${headers}|
|the response should contain |${element} |equal to |${value} |or |${second_element} |equal to |${second_value}|

And the test wiki would be:

!define TEST_SYSTEM {slim}
!define server {http://admin:password@localhost:5984/}
!define headers { !-Authorization: Basic YWRtaW46cGFzc3dvcmQ=
Accept: application/json -! }
!define service {/q-couch/}
!define element {ok}
!define value {0}
!define second_element {error}
!define second_value {not_found}

!include PathTo.BuildingBlock

Some of the defines above, I probably would have put in the SetUp wiki.

Community
  • 1
  • 1
D. Josefsson
  • 1,052
  • 7
  • 21