LiveDoc - smartrics/RestFixture GitHub Wiki

SuiteSetUp

 
Precompiled Libraries



variable defined: ns1=

variable defined: defns=




Import
smartrics.rest.fitnesse.fixture
smartrics.rest.test.fitnesse.fixture






script
Http Server Fixture
check is started

false

start server 9876
check is started

true



 
Configure the RestFixture with named configuration table of key value pairs
Read more aboutRestFixtureConfig






Table: Rest Fixture Config
http.client.connection.timeout

5000

http.client.use.new.http.uri.factory

false

restfixture.display.actual.on.right

true

restfixture.display.toggle.for.cells.larger.than

200

restfixture.default.headers

defHeader : 1

anotherDefHeader : 2

restfixture.xml.namespace.context

ns1alias=http://smartrics/ns1 

 defalias=http://smartrics/defns

restfixture.content.default.charset

UTF-8

restfixture.content.handlers.map

application/xml=XML

application/json=JSON

text/plain=TEXT

default=XML

application/x-javascript=JS

CollapseableContent

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database


In the interest of readability, cells with large content can be rendered with a toggle on/off button.

The minimum length in characters of the cell, in order to enable the toggle button, is specified with the property

restfixture.display.toggle.for.cells.larger.than

If the value of the property is negative the toggle button will not be rendered.

Currently only large HTTP response content cells (if the actual value is displayed) are enabled for toggling.





Table: Rest Fixture
http://localhost:9876
GET /resources/100

200

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 910

Server : Jetty(6.0.2)

/resource/type[text()=‘large content’]


expected



toggle actual

<resource>

   <name>giant bob</name>

   <type>large content</type>

   <address>

       <street>

            Regent Street

       </street>

       <number>

            12345

       </number>

   </address>

   <data>

       <part id=‘0’>

           <source href=‘http://en.wikipedia.org/wiki/Inferno_(Dante)’ />

           <content>

Inferno (Italian for ‘Hell’) is the first part of Dante Alighieri’s 14th-century epic poem Divine Comedy. 

It is followed by Purgatorio and Paradiso. It is an allegory telling of the journey of Dante through what is 

largely the medieval concept of Hell, guided by the Roman poet Virgil. In the poem, Hell is depicted as nine 

circles of suffering located within the Earth. Allegorically, the Divine Comedy represents the journey of the soultowards God, with the Inferno describing the recognition and rejection of sin.

           </content>

       </part>

   </data>

</resource>



actual

DeleteTests

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database



 
Note
You may not want to specify any expectation neither in the header cell nor in the body cell, as in the GET below






Table: Rest Fixture
http://localhost:9876
DELETE /resources/0

204

Server : Jetty(6.0.2)

no-body

GET /resources/0

404

Content-Length : 0

Server : Jetty(6.0.2)
no-body

FailingGetTest

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database



 
Rest requests with query string containing array parameters
A query string can contain parameter arrays and they are correctly handled by Rest Fixture.


To allow correct handling of array parameters a new configuration option must be set: http.client.use.new.http.uri.factory





Table: Rest Fixture Config
withArrayParametersSupport
http.client.use.new.http.uri.factory

true






Table: Rest Fixture
http://localhost:9876 withArrayParametersSupport
GET /resources/0?a0=2&a1=4

200

Query-String : a0=2&a1=4

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 183

Server : Jetty(6.0.2)
<resource>

    <name>a funky name</name>

    <data>an important message</data>

    <nstag xmlns:ns1=‘http://smartrics/ns1’>

        <ns1:number>3</ns1:number>

    </nstag>

</resource>

GetTests

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database



 
Notes
A GET request is performed on the resource whose URI is specified in the second cell.

The following cell indicate:

1) the expected return HTTP code,

2) a subset of headers – regular expressions are allowed

3) a list of XPaths to be executed in the body. Each XPath is run and it suceedes only if the result of the execution

returns at least one node






Table: Rest Fixture
http://localhost:9876
GET /resources/0

200

Content-Length : [\d]+


expected



Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 183

Server : Jetty(6.0.2)


actual



 /resource/name[text()=‘a funky name’] <br/>

 /resource/data[text()=‘an important message’]



expected



<resource>

    <name>a funky name</name>

    <data>an important message</data>

    <nstag xmlns:ns1=‘http://smartrics/ns1’>

        <ns1:number>3</ns1:number>

    </nstag>

</resource>


actual



 
Absolute resource paths
A GET (as all other verbs) accepts absolute resource paths.






Table: Rest Fixture
http://localhost:9876
GET /resources/0

200

Content-Length : [\d]+


expected



Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 183

Server : Jetty(6.0.2)


actual



 /resource/name[text()=‘a funky name’] <br/>

 /resource/data[text()=‘an important message’]



expected



<resource>

    <name>a funky name</name>

    <data>an important message</data>

    <nstag xmlns:ns1=‘http://smartrics/ns1’>

        <ns1:number>3</ns1:number>

    </nstag>

</resource>


actual


A GET request properly handles query strings. In this example the stub resource echoes the query string in a Query-String header





Table: Rest Fixture
http://localhost:9876
GET /resources/0?param=echome&something=else&another=parameter

200

Content-Length : [\d]+

Query-String : param=echome&something=else&another=parameter 


expected



Query-String : param=echome&something=else&another=parameter

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 183

Server : Jetty(6.0.2)


actual



 /resource/name[text()=‘a funky name’] <br/>

 /resource/data[text()=‘an important message’]



expected



<resource>

    <name>a funky name</name>

    <data>an important message</data>

    <nstag xmlns:ns1=‘http://smartrics/ns1’>

        <ns1:number>3</ns1:number>

    </nstag>

</resource>


actual


Get a non existing resource should not find it


 
Note
Instead of XPaths you can specify ‘no-body’ if the operation is expected to return an empty body






Table: Rest Fixture
http://localhost:9876
GET /resources/20

404

Content-Length : 0


expected



Content-Length : 0

Server : Jetty(6.0.2)


actual

no-body

GET /resources/20.json

404

Content-Length : 0


expected



Content-Length : 0

Server : Jetty(6.0.2)


actual

no-body



 
XPaths and namespaces
Namespaces are supported by declaring the alias/uri map in theRestFixtureConfig, using the key restfixture.xml.namespace.context (SeeSuiteSetup)






Table: Rest Fixture
http://localhost:9876
GET /resources/0

200

Content-Length : [\d]+


expected



Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 183

Server : Jetty(6.0.2)


actual



 /resource/nstag/ns1alias:number[text()=‘3’]



expected



<resource>

    <name>a funky name</name>

    <data>an important message</data>

    <nstag xmlns:ns1=‘http://smartrics/ns1’>

        <ns1:number>3</ns1:number>

    </nstag>

</resource>


actual



 
Json
Expectations can be asserted also in json format for responses whose content type is ‘application/json’ or ‘application/x-javascript’






Table: Rest Fixture
http://localhost:9876
GET /resources/1.json

200

Content-Type : application/json;charset=ISO-8859-1


expected



Content-Type : application/json;charset=ISO-8859-1

Content-Length : 77

Server : Jetty(6.0.2)


actual



 /resource/name[text()=‘a funky name’] <br/>

 /resource/data[text()=‘an important message’]



expected



{ “resource” : { “name” : “a funky name”, “data” : “an important message” } }


actual



 
Rest requests with query string containing array parameters
A query string can contain parameter arrays and they are correctly handled by Rest Fixture.


To allow correct handling of array parameters a new configuration option must be set: http.client.use.new.http.uri.factory





Table: Rest Fixture Config
withArrayParametersSupport
http.client.use.new.http.uri.factory

true






Table: Rest Fixture
http://localhost:9876 withArrayParametersSupport
GET /resources/0?a0=2&a1=4

200

Query-String : a0=2&a1=4

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 183

Server : Jetty(6.0.2)
<resource>

    <name>a funky name</name>

    <data>an important message</data>

    <nstag xmlns:ns1=‘http://smartrics/ns1’>

        <ns1:number>3</ns1:number>

    </nstag>

</resource>



 
Follow redirects setting
To allow redirects to be followed automatically or not the configuration paramerer
restfixture.requests.follow.redirects

needs to be set (defaults to true)







Table: Rest Fixture Config
withFollowRedirect
restfixture.requests.follow.redirects

false






Table: Rest Fixture
http://localhost:9876 withFollowRedirect
GET /resources/redirect/0

301

Location: /resources/0


expected



Location : /resources/0

Content-Length : 0

Server : Jetty(6.0.2)


actual

no-body






Table: Rest Fixture Config
withFollowRedirect
restfixture.requests.follow.redirects

true






Table: Rest Fixture
http://localhost:9876 withFollowRedirect
GET /resources/redirect/0

200

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 183

Server : Jetty(6.0.2)
<resource>

    <name>a funky name</name>

    <data>an important message</data>

    <nstag xmlns:ns1=‘http://smartrics/ns1’>

        <ns1:number>3</ns1:number>

    </nstag>

</resource>


HeadTests

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database


Head requests should return no-body but the headers list should match that of the equivalent GET operation.





Table: Rest Fixture
http://localhost:9876
GET /resources/0

200

Content-Length : [\d+]


expected



Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 183

Server : Jetty(6.0.2)


actual

<resource>

    <name>a funky name</name>

    <data>an important message</data>

    <nstag xmlns:ns1=‘http://smartrics/ns1’>

        <ns1:number>3</ns1:number>

    </nstag>

</resource>
let length header Content-Length:(.+) 183
let type header Content-Type:(.+) application/xml;charset=ISO-8859-1
HEAD /resources/0

200

Content-Length : %length%


expected



Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 183

Server : Jetty(6.0.2)


actual

no-body

HEAD /resources/0

200

Content-Type: %type%


expected



Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 183

Server : Jetty(6.0.2)


actual

no-body

JavascriptExpectations

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database


Expectations in Javascript on responses with content type application/json



As of RestFixture Version 2, a javascript engine is embedded to allow expectations in Javascript on response body contents in JSON format.


 
XPaths and JSON
For backward compatibility XPath expressions are maintained and executed


After a successful response is received with content type “application/json” the expectation cell in a RestFixture[?]
row is


interpreted as a string with Javascript and executed within the context of the response body.





Table: Rest Fixture
http://localhost:9876
setBody { “resource” : { “name” : “test post”, “data” : “some data” } }
POST /resources/

201

Location : /resources/2

Content-Length : 0

Server : Jetty(6.0.2)

no-body

let id header Location:/resources/(.+) 2


A variable <code>jsonbody</code> is defined holding the JSON in the response.

The test passes if the result of the evaluation of the cell is a boolean.





Table: Rest Fixture
http://localhost:9876
GET /resources/2.json

200

Content-Type : application/json


expected



Content-Type : application/json;charset=ISO-8859-1

Content-Length : 65

Server : Jetty(6.0.2)


actual



jsonbody.resource.name"test post" && jsonbody.resource.data“some data” 



expected



 { “resource” : { “name” : “test post”, “data” : “some data” } } 


actual


It is possible to specify multiple assertions, one for each line.

The test passes if each line evaluates to true.





Table: Rest Fixture
http://localhost:9876
GET /resources/2.json

200

Content-Type : application/json


expected



Content-Type : application/json;charset=ISO-8859-1

Content-Length : 65

Server : Jetty(6.0.2)


actual



jsonbody.resource.name.length >= 0 

jsonbody.resource.name.length < 1000

jsonbody.resource.name.length < jsonbody.resource.name.length+1



expected



 { “resource” : { “name” : “test post”, “data” : “some data” } } 


actual

let content js response.body  { “resource” : { “name” : “test post”, “data” : “some data” } } 






Table: Rest Fixture
http://localhost:9876
setBody

%content%


expected



 { “resource” : { “name” : “test post”, “data” : “some data” } } 


actual

POST /resources/

201

Location : /resources/3

Content-Length : 0

Server : Jetty(6.0.2)

no-body

let id header Location:/resources/(.+) 3


In some cases may be useful to force evaluation of the expectation cell as a javascript block.

By embedding the <code>/* javascript */</code> comment, the whole expectation cell will be parsed and evaluated entirely using the javascript interpreter.





Table: Rest Fixture
http://localhost:9876
GET /resources/3.json

200

Content-Type : application/json


expected



Content-Type : application/json;charset=ISO-8859-1

Content-Length : 65

Server : Jetty(6.0.2)


actual



/ javascript /

var concat = jsonbody.resource.name  “ and ”  jsonbody.resource.data

concat==“test post and some data” 



expected



 { “resource” : { “name” : “test post”, “data” : “some data” } } 


actual

let content js response.body  { “resource” : { “name” : “test post”, “data” : “some data” } } 


LetTests

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database


Usages of LET (See alsoPostTests
for more examples)


LET used to extract values from header, using regular expressions





Table: Rest Fixture
http://localhost:9876
setBody

<resource><name>Bill</name><data>Some data on Bill</data></resource>


expected



<resource><name>Bill</name><data>Some data on Bill</data></resource>


actual

POST /resources/

201

Location : /resources/2

Content-Length : 0

Server : Jetty(6.0.2)

no-body

let id header Location:/resources/(.+) 2


The regex is applied to each header. On the first match the first group is extracted and

assigned as value to the label
id.

Labels are global and can be shared across rest fixture instances.

LET used to extract values from XML body via XPath

Values are re-usable across instances of RestFixture

Here follows an usage of the previously extracted
id.

This example also shows how to use let to extract data from the XML body of a response using XPath.





Table: Rest Fixture
http://localhost:9876
GET /resources/2

200

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 68

Server : Jetty(6.0.2)



 /resource/name[text()=‘Bill’]<br/>

 /resource/data[text()=‘Some data on Bill’]



expected



<resource><name>Bill</name><data>Some data on Bill</data></resource>


actual

let name body /resource/name/text() Bill


…or from a JSON body





Table: Rest Fixture
http://localhost:9876
GET /resources/1.json

200

Content-Type : application/json


expected



Content-Type : application/json;charset=ISO-8859-1

Content-Length : 77

Server : Jetty(6.0.2)


actual



 /resource/name[text()=‘a funky name’]<br/>

 /resource/data[text()=‘an important message’]

 


expected



{ “resource” : { “name” : “a funky name”, “data” : “an important message” } }


actual

let name body /resource/name/text() a funky name



 
Note
Label values can be accessed from code using
new Variables().get(“labelname”);


LET resolves names from Fixture Symbol map if not found in the local map

LetTestActionFixture allows to get/set values in the Fixture Symbol map





script
smartrics.rest.test.fitnesse.fixture.LetTestActionFixture
symbolName resType
symbolValue /resources



 
Note
Look at the source code of this page to see that the resource URI

for the GET method below is defined as
%resType%/%id%






Table: Rest Fixture
http://localhost:9876
GET /resources/2

200

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 68

Server : Jetty(6.0.2)
<resource><name>Bill</name><data>Some data on Bill</data></resource>
let theName body /resource/name/text() Bill






script
smartrics.rest.test.fitnesse.fixture.LetTestActionFixture
symbolName theName
check symbolValue

Bill


Other fixtures can set a value in the symbol map with
Fixture.setSymbol.

The RestFixture[?]
can then pick them up


This fixture sets
symbolName=/resources





script
smartrics.rest.test.fitnesse.fixture.LetTestActionFixture
symbolName aNameOfASymbol
symbolValue /resources


… then the value is used by the RestFixture





Table: Rest Fixture
http://localhost:9876
GET /resources/2

200

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 68

Server : Jetty(6.0.2)
<resource><name>Bill</name><data>Some data on Bill</data></resource>


LetTestsV2

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database


LET can use now the full power of JavaScript to extract data from the last response parts. The additions

to support the new JavaScript extensions will not break the existing RestFixture API.

The JavaScript extensions can be used to process more effectively JSON
Content-Types.

LET can access the Fitnesse Symbols map to extract data previously stored

If the context of the let context is
js
the expression is evaluated as a javascript string. The value assigned


to the let label is the result of the evaluation of the content in the expression cell.

For example:





Table: Rest Fixture
http://localhost:9876
let message js ‘Hello, World!’

Hello, World!

let sum js ‘2 + 5 = ’  (2  5)

2 + 5 = 7

let two_expressions js a=1;

‘a is ’ + a

a is 1

let json_expr js


json = {

    widget

        debug;“on”,

        window

            title;“Sample Konfabulator Widget”,

            name;“main_window”,

            width,

            height

        },

        image;

            src;“Images/Sun.png”,

            name;“sun1”,

            hOffset,

            vOffset,

            alignment;“center”

        },

        text

            data;“Click Here”,

            size,

            style;“bold”,

            name;“text1”,

            hOffset,

            vOffset,

            alignment;“center”,

            onMouseUp;“sun1.opacity = (sun1.opacity / 100) * 90;”

        }

    }

};

json.widget.image.src

Images/Sun.png


(Example courtesy ofhttp://json.org/example.html)

It’s also possible to access the FitNesse symbols map. The scope where expression is evaluated contains the

‘symbols’ object





Table: Rest Fixture
http://localhost:9876
setBody

<resource><name>Bill</name><data>Some data on Bill</data></resource>


expected



<resource><name>Bill</name><data>Some data on Bill</data></resource>


actual

POST /resources/

201

Location : /resources/2

Content-Length : 0

Server : Jetty(6.0.2)

no-body

let id header Location:/resources/(.+) 2
let id_string js ‘The id is: ’ + symbols.get(‘id’)

The id is: 2


The scope also contains the ‘response’ object, populated with the data from the last Rest response executed

For example





Table: Rest Fixture
http://localhost:9876
GET /resources/1

200

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 77

Server : Jetty(6.0.2)
{ “resource” : { “name” : “a funky name”, “data” : “an important message” } }
let body_value js response.body { “resource” : { “name” : “a funky name”, “data” : “an important message” } }
setBody

<resource><name>Bill</name><data>Some data on Bill</data></resource>


expected



<resource><name>Bill</name><data>Some data on Bill</data></resource>


actual

POST /resources/

201

Location : /resources/3

Content-Length : 0

Server : Jetty(6.0.2)

no-body

let status_code_value js response.statusCode 201
let status_text_value js response.statusText Created
let c_len js response.header0(‘Content-Length’)

0

let loc_again js response.header(‘Location’, 0) /resources/3
let h_size js response.headerListSize(‘Location’)

1

let all_h_size js response.headersSize() 3


A particoular case is when the response is JSON (Content-Type : application/json). In such case, the property
jsonbody

contains the JSON object that can be accessed using the dot notation. For example





Table: Rest Fixture
http://localhost:9876
GET /resources/1.json

200

Content-Type : application/json;charset=ISO-8859-1

Content-Length : 77

Server : Jetty(6.0.2)
{ “resource” : { “name” : “a funky name”, “data” : “an important message” } }
let body_value js response.jsonbody [object Object]
let body_value js response.jsonbody.resource.name

a funky name


OptionsTests

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database


Options requests are supported too:





Table: Rest Fixture
http://localhost:9876
OPTIONS /resources/0

200

Allow:.+

Content-Length : 0


expected



Allow : GETHEADPOSTPUTDELETETRACEOPTIONS

Content-Length : 0

Server : Jetty(6.0.2)


actual

no-body

OverrideContentHandlers

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database


RestFixture uses three content handlers to parse and set expectations used to verify the behaviour of HTTP calls.

These are the handlers currently available:



  • XML
    interprets the body as an xml string and allows XPath expressions as expectations on that content
  • JSON
    interprets the body as a JSON string and allows expectations to be written in JavaScript
    [?].

  • TEXT
    interprets the body as a string and allows regular expression expectations.


These are the defaults


  • default=XML

  • application/xml=XML

  • application/json=JSON

  • text/plain=TEXT



 
Note: unrecognised content types.
Content types not recogised will be mapped to the default content handler (XML).


For example, XML handler is used for for content types of application/xml; hence XPaths can be used to set expectations:





Table: Rest Fixture
http://localhost:9876
GET /resources/0

200

Content-Type : application/xml;.+


expected



Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 183

Server : Jetty(6.0.2)


actual



 /resource/name[text()=‘a funky name’] <br/>

 /resource/data[text()=‘an important message’]



expected



<resource>

    <name>a funky name</name>

    <data>an important message</data>

    <nstag xmlns:ns1=‘http://smartrics/ns1’>

        <ns1:number>3</ns1:number>

    </nstag>

</resource>


actual


Bespoke mapping can be defined in the config using the config key
restfixture.content.handlers.map





Table: Rest Fixture Config
overridesContentHandlerConfig
restfixture.content.handlers.map



application/xml=TEXT






Table: Rest Fixture
http://localhost:9876 overridesContentHandlerConfig
GET /resources/0

200

Content-Type : application/xml;.+


expected



Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 183

Server : Jetty(6.0.2)


actual

<resource>[\s.]<name>a funky name</name>[\s\w\d<>/=\:’.]</resource>[\s]*


expected



<resource>

    <name>a funky name</name>

    <data>an important message</data>

    <nstag xmlns:ns1=‘http://smartrics/ns1’>

        <ns1:number>3</ns1:number>

    </nstag>

</resource>


actual


PostTests

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database


Posting an XML should create a resource


 
Note
You set the body for the POST operation with the setBody.

Here you can see how
let
is used. The first cell is the

label
of the variable.


The follwoing cell indicates where to get the data from. That is either the
header
or the body of the last successful HTTP response


Then the expression to extract the value to be assigned to he variable. For
header
it has to be a regular expression, for body it


has to be an XPath whose execution must return a String node.






Table: Rest Fixture
http://localhost:9876
setBody

<resource><name>test post</name><data>some data</data></resource>


expected



<resource><name>test post</name><data>some data</data></resource>


actual

POST /resources

201

Location : /resources/2

Content-Length : 0

Server : Jetty(6.0.2)

no-body

let id header Location:/resources/(.+) 2



 
Note
Variables are global: here the GET op is executed on an URI containing
%id%
where the label ‘id’ is defined in the test above.


The test succeedes only if the resulting XPath match the XML used for the creation of the resource.

You can also put variables in the expected result

The subsequent
let
operation shows how to use XPaths in the body.



Label values can be accessed from code using
new Variables().get(“labelname”);



 
Note on fit.Fixture symbol map
Labels are implemented on top of the Fitnesse symbols map. So every label set via RestFixture is accessible via
fit.Fixture.getSymbol().


If a label starts with $, the $ is ignored.






Table: Rest Fixture
http://localhost:9876
GET /resources/2

200

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 65

Server : Jetty(6.0.2)



 /resource/name[text()=‘test post’]<br/>

 /resource/data[text()=‘some data’]



expected



<resource><name>test post</name><data>some data</data></resource>


actual

let name body /resource/name/text() test post
let $symName body /resource/name/text() test post


Labels that are set to null are rendered using the default value for null, e.g. the string “null”





Table: Rest Fixture
http://localhost:9876
GET /resources/2

200

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 65

Server : Jetty(6.0.2)
<resource><name>test post</name><data>some data</data></resource>
let thisIsNull body /resource/somewhereelse/text()
comment this is null: ‘null’


Albeit, the value can be overridden





Table: Rest Fixture Config
withBespokeNullRepresentation
restfixture.null.value.representation






Table: Rest Fixture
http://localhost:9876 withBespokeNullRepresentation
GET /resources/2

200

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 65

Server : Jetty(6.0.2)
<resource><name>test post</name><data>some data</data></resource>
let thisIsNull body /resource/somewhereelse/text()
comment this is null: ’’






Table: Rest Fixture Config
withBespokeNullRepresentation
restfixture.null.value.representation

NIL






Table: Rest Fixture
http://localhost:9876 withBespokeNullRepresentation
GET /resources/2

200

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 65

Server : Jetty(6.0.2)
<resource><name>test post</name><data>some data</data></resource>
let thisIsNull body /resource/somewhereelse/text()
comment this is null: ‘NIL



 
Json
Expectations can be asserted also in json format for responses whose content type is ‘application/json’

Variables may be substitued in the expected result






Table: Rest Fixture
http://localhost:9876
setBody { “resource” : { “name” : “test post”, “data” : “some data” } }
POST /resources/

201

Location : /resources/3

Content-Length : 0

Server : Jetty(6.0.2)

no-body

let id header Location:/resources/(.+) 3






Table: Rest Fixture
http://localhost:9876
GET /resources/3.json

200

Content-Type : application/json


expected



Content-Type : application/json;charset=ISO-8859-1

Content-Length : 65

Server : Jetty(6.0.2)


actual



  /resource/name[text()=‘test post’] <br/>

  /resource/data[text()=‘some data’]



expected



 { “resource” : { “name” : “test post”, “data” : “some data” } } 


actual



 
File uploads
Use the multipartFile property to upload files to a server






script
smartrics.rest.test.fitnesse.fixture.FileUtilFixture
content { “resource” : { “name” : “test post”, “data” : “some data” } }
name target/live-docs-temp/tempfile
check create

true

check exists

true






Table: Rest Fixture
http://localhost:9876
setMultipartFileName target/live-docs-temp/tempfile
POST /resources/

200

Content-Type : text/plain; charset=ISO-8859-1

Transfer-Encoding : chunked

Server : Jetty(6.0.2)

file: { “resource” : { “name” : “test post”, “data” : “some data” } }






Table: Rest Fixture
http://localhost:9876
setMultipartFileName target/live-docs-temp/tempfile
setMultipartFileParameterName abc123
POST /resources/

200

Content-Type : text/plain; charset=ISO-8859-1

Transfer-Encoding : chunked

Server : Jetty(6.0.2)

abc123: { “resource” : { “name” : “test post”, “data” : “some data” } }


Use simple file upload





Table: Rest Fixture
http://localhost:9876
setFileName target/live-docs-temp/tempfile
POST /resources/

200

Content-Type : text/plain; charset=ISO-8859-1

Transfer-Encoding : chunked

Server : Jetty(6.0.2)

{ “resource” : { “name” : “test post”, “data” : “some data” } }






script
smartrics.rest.test.fitnesse.fixture.FileUtilFixture
name target/live-docs-temp/tempfile
check delete

true

check exists

false


Other than the aforementioned content types you can emulate form POSTs.

Remember to escape the setBody content cell with





Table: Rest Fixture
http://localhost:9876
setHeader Content-Type : application/x-www-form-urlencoded;charset=UTF-8
setBody name=test%20post&data=some%20data
POST /resources

201

Location : /resources/4

Content-Length : 0

Server : Jetty(6.0.2)

no-body

let id header Location:/resources/(.+) 4






Table: Rest Fixture
http://localhost:9876
GET /resources/4

200

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 68

Server : Jetty(6.0.2)



 /resource/name[text()=‘test post’]

 /resource/data[text()=‘some data’]



expected



<resource>

<name>test post</name>

<data>some data</data>

</resource>


actual


Header values can also be substituted with symbols previously defined:





Table: Rest Fixture
http://localhost:9876
let contenttype const application/x-www-form-urlencoded;charset=UTF-8 application/x-www-form-urlencoded;charset=UTF-8
setHeader Content-Type : application/x-www-form-urlencoded;charset=UTF-8
setBody name=test%20post&data=some%20data
POST /resources

201

Location : /resources/5

Content-Length : 0

Server : Jetty(6.0.2)

no-body

let id header Location:/resources/(.+) 5






Table: Rest Fixture
http://localhost:9876
GET /resources/5

200

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 68

Server : Jetty(6.0.2)



 /resource/name[text()=‘test post’]

 /resource/data[text()=‘some data’]



expected



<resource>

<name>test post</name>

<data>some data</data>

</resource>


actual


PutTests

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database



 
Note
This test shows how to pass bespoke headers in the request. In this specific case, the stub echoes back the ‘Echo-Header’, so that the

following PUT and GET can match it the response.






Table: Rest Fixture
http://localhost:9876
setBody

<resource><name>name being updated</name><data>data being updated</data></resource>


expected



<resource><name>name being updated</name><data>data being updated</data></resource>


actual

setHeader Echo-Header : echoed
PUT /resources/0

200

Echo-Header : echoed


expected



Echo-Header : echoed

Content-Length : 0

Server : Jetty(6.0.2)


actual

no-body

GET /resources/0

200

Echo-Header : echoed


expected



Echo-Header : echoed

Content-Type : application/xml;charset=ISO-8859-1

Content-Length : 83

Server : Jetty(6.0.2)


actual



 /resource/name[text()=‘name being updated’] <br/>

 /resource/data[text()=‘data being updated’]



expected



<resource><name>name being updated</name><data>data being updated</data></resource>


actual

TraceTests

 
Precompiled Libraries





 
Included page: .RestFixtureTests.SetUp (edit)





script
smartrics.rest.test.fitnesse.fixture.HttpServerFixture
check is started

true

reset resources database


TRACE requests are supported too:





Table: Rest Fixture
http://localhost:9876
TRACE /resources/0

200

Content-Type : message/http


expected



Content-Type : message/http

Content-Length : 130

Server : Jetty(6.0.2)


actual

TRACE /resources/0 HTTP/1.1

anotherDefHeader: 2

defHeader: 1

User-Agent: Jakarta Commons-HttpClient/3.1

Host: localhost:9876

SuiteTearDown

 
Precompiled Libraries



script

smartrics.rest.test.fitnesse.fixture.HttpServerFixture

check is started

true

stop server
check is stopped

true

⚠️ **GitHub.com Fallback** ⚠️