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:
Frank2Manual/tests/hermesBridge/common.propertiesand open it in a text editor.
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
serviceName. You are defining a service named
adapter.toConscience, so you have to set the properties
The values of these properties appear after the
= sign. You already learned why the value of the
className property is
serviceName you set the destination to which your IbisJavaSender is writing. This is the service name of the “JavaListener” you are accessing, which is
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
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:
Frank2Manual/tests/hermesBridge/scenario01.propertiesand open it in a text editor.
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:
Extend your file
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:
Fill it with the example Hermes-formatted address request you find in subsection Stubbing.
Extend your file
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
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:
scenario.description = Hermes requests address from Conscience include = common.properties step1.adapter.toConscience.write = scenario01/hermesAddressRequest.xml step2.stub.conscience.read = scenario01/conscienceAddressRequest.xml
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:
Frank2Manual/tests/hermesBridge/scenario01/conscienceAddress.xml. Fill it with the example of a Conscience address.
Frank2Manual/tests/hermesBridge/scenario01/hermesAddress.xml. Fill it with the example of a Hermes address.
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:
In the main menu of the Frank!Console, go to Testing | Larva. Your screen should look like shown below:
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).
All your tests should succeed. Please check this (see number 4).
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.
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
stubfor the first word, making clear the role this service plays in your tests. Each service has a property
classNamethat 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.