Services

In subsection Stubbing, you learned that the Frank!Framework can alter adapters such that they can easily be unit tested. You were introduced to an example Frank “Frank2Hermes”. You saw that its HTTP interfaces were replaced by a JavaListener and an IbisJavaSender, which work with direct Java calls. In this subsection you will write the test. This will introduce you to Larva services.

Defining your services

Please start writing your Larva test by doing the following:

1. Create file Frank2Manual/tests/hermesBridge/common.properties and open it in a text editor.

2. Give this file the following contents:

   adapter.toConscience.className = nl.nn.adapterframework.senders.IbisJavaSender
   adapter.toConscience.serviceName=testtool-adapterToConscience
   

You have defined a service that can interact with listener “testtool-adapterToConscience”. Your service writes to a listener, so it has to be a sender. The listener is of type “JavaListener”, so your sender should issue direct Java calls. Therefore, your sender needs to be of type “IbisJavaSender”. To define the sender, you reference the Java class that implements it. In the Frank!Framework source code, class nl.nn.adapterframework.senders.IbisJavaSender implements senders of type “IbisJavaSender”.

Services are defined by assigning properties. Services of type “IbisJavaSender” have two properties, namely className and serviceName. You are defining a service named adapter.toConscience, so you have to set the properties adapter.toConscience.className and adapter.toConscience.serviceName.

The values of these properties appear after the = sign. You already learned why the value of the className property is nl.nn.adapterframework.senders.IbisJavaSender. In serviceName you set the destination to which your IbisJavaSender is writing. This is the service name of the “JavaListener” you are accessing, which is testtool-adapterToConscience.

3. Add your testtool-pipeCallConscience service to common.properties. Extend this file as shown:

   adapter.toConscience.className = nl.nn.adapterframework.senders.IbisJavaSender
   adapter.toConscience.serviceName=testtool-adapterToConscience
   
   stub.conscience.className = nl.nn.adapterframework.receivers.JavaListener
   stub.conscience.serviceName= testtool-pipeCallConscience
   

Your service testtool-pipeCallConscience is accessed by your system under test “Frank2Hermes”. “Frank2Hermes” writes to your test service, so your service should be a listener. “Frank2Hermes” calls your service through direct Java calls, so your service should be of type “JavaListener”. This type of service is implemented by Java class nl.nn.adapterframework.receivers.JavaListener. You name your service stub.conscience, so your Java class name should be the value of property stub.conscience.className. This explains the first line you added.

Services of type “JavaListener” also have a property serviceName, but it has a different meaning. The service name of a JavaListener identifies it for senders of type “IbisJavaSender”. An IbisJavaSender references the destination to write to by the service name. We explained earlier that the Frank!Framework modified the sender within Frank2Hermes to access listener testtool-pipeCallConscience. This is the serviceName we need for our service. To set the serviceName of service stub.conscience, we have to set property stub.conscience.serviceName. This explains the second line.

Writing your test

Now that you have your services, you can use them to write a unit test. Please continue as follows:

4. Create file Frank2Manual/tests/hermesBridge/scenario01.properties and open it in a text editor.

5. Give this file the following contents:

   scenario.description = Hermes requests address from Conscience
   

It is wise to give your scenario a description. When you have multiple tests, you will see all their descriptions when you run them. This shows you what features of your adapters are covered by your tests. When there are failing tests, the descriptions will help you to spot the issue.

Your scenario needs the services you have defined in common.properties. Please do the following to include this file:

6. Extend your file scenario01.properties as shown:

   scenario.description = Hermes requests address from Conscience
   
   include = common.properties
   

Next, you will write a Hermes-formatted address request to your system-under-test “Frank2Hermes”. This is message 1 in the figure to the bottom of the previous subsection Stubbing. To the top of that subsection, you already saw an example Hermes-formatted address request. Please continue as follows:

7. Create file Frank2Manual/tests/hermesBridge/scenario01/hermesAddressRequest.xml.

8. Fill it with the example Hermes-formatted address request you find in subsection Stubbing.

9. Extend your file scenario01.properties as shown:

   scenario.description = Hermes requests address from Conscience
   
   include = common.properties
   
   step1.adapter.toConscience.write = scenario01/hermesAddressRequest.xml
   

You see a new syntax here that needs explanation. The file you are writing appears to the right of the = sign. The property name before the = sign has to: a) command that the mentioned file is to be written; b) specify the service that has to do the writing; and c) specify when the write has to happen. Point (c) is expressed by the first word step1. Point (b) is pressed by the next two words adapter.toConscience. Point (a) is expressed by the last word write.

You will continue with message 2 of the figure of subsection Stubbing. Now a message is coming from your system-under-test, and you have to read this message. The read command compares the read text with the file mentiond to the right of the = sign. You test here that “Frank2Hermes” transforms a Hermes address request correctly into a Conscience address request. The reading has to be done by service stub.conscience and it is step2 of your scenario. Please continue as follows:

10. Extend scenario01.properties as shown:

    scenario.description = Hermes requests address from Conscience
    
    include = common.properties
    
    step1.adapter.toConscience.write = scenario01/hermesAddressRequest.xml
    step2.stub.conscience.read = scenario01/conscienceAddressRequest.xml
    

11. Create file Frank2Manual/tests/hermesBridge/scenario01/conscienceAddressRequest.xml. Fill it with the example Conscience address request you can find in subsection Stubbing.

You have seen all Larva syntax you need to finish your test. You need to write message 3, the response to “Frank2Hermes” that is the Conscience-formatted address. The writing has to be done by service stub.conscience. Finally your test needs to read message 4, the Hermes-formatted address, comparing it with the address you expect. Please continue as follows:

12. Create file Frank2Manual/tests/hermesBridge/scenario01/conscienceAddress.xml. Fill it with the example of a Conscience address.

13. Create file Frank2Manual/tests/hermesBridge/scenario01/hermesAddress.xml. Fill it with the example of a Hermes address.

14. Finish scenario01.properties as shown:

    scenario.description = Hermes requests address from Conscience
    
    include = common.properties
    
    step1.adapter.toConscience.write = scenario01/hermesAddressRequest.xml
    step2.stub.conscience.read = scenario01/conscienceAddressRequest.xml
    step3.stub.conscience.write = scenario01/conscienceAddress.xml
    step4.adapter.toConscience.read = scenario01/hermesAddress.xml
    

Running your test

Please try your test as follows:

15. In the main menu of the Frank!Console, go to Testing | Larva. Your screen should look like shown below:

    

16. You see you are in Larva (number 1). Select that you want to run all your tests (”\\” in number 2) and press “start” (number 3).

17. All your tests should succeed. Please check this (see number 4).

18. A test scenario is a sequence of steps that depend on each other. You should have one scenario named “hermesBridge/scenario01”. Please check that you see the decription you entered earlier.

19. You see all four steps of your scenario (number 6 shows step 1). If a step fails it becomes red, showing you where the problem occurs.

Summary of Larva syntax

You have seen how to write a Larva test for integrations that use the request-reply integration pattern. You have learned most of the syntax of writing Larva tests. Here is a summary:

Service definition

Service definition lines have properties with three words, like service.name.propertyName. A service name always has two words. It is good practice to use adapter or stub for the first word, making clear the role this service plays in your tests. Each service has a property className that identifies the kind of service by a Java classname. Each kind of service defines different properties.

Scenario description

Each scenario defines property scenario.description, providing a description of the scenario. This description is shown in the user interface of Larva.

Include statement

Each scenario can include files using the syntax include = <file name>. The file name is a relative path, relative to the directory of your scenario properties file (e.g. scenario01.properties). You can have multiple lines like include = to include multiple files.

Test command

Your test consists of commands like step<n>.service.name.<read or write> = <file name>. The file name is either the file to write, or the file to compare with the read result. The file name is a relative path, relative to the scenario properties file.