Objective

By the end of this blog, we will know:

  1. How to mock a Camel Message in your IDE for testing?
  2. What is TDD (Test Driver Dev) and BDD (Behaviour Driven Dev)?
  3. What is Spock and how it can simplify your testing?

Table of Contents

  1. Objective
  2. Mocking a Camel Message in your IDE
  3. TDD vs BDD: Practical Differences for Developers
  4. Spock and TDD
  5. Groovy Script Testing with Spock
  6. Whats next?

Mocking a Camel Message in your IDE

While this can be a separate article “How to mock an Interface?”, I will just touch upon the topic here. As we understood from Blog 3 that in context of “Groovy scripting in Cloud integration”, the Message object is part of Script API library which implements a lot more methods than we are interested in.

So if you try to Create a message object from com.sap.gateway.ip.core.customdev.util.Message it will force you to implement all the underlying methods.

That is why we need to create a mock up of the Message object which contains only the get set methods essentially related to only headers, body and properties.

Below is a complete Mock Message Class which you can use in your Test project to mock the message object. Just Create a project -> Create a package com.sap.gateway.ip.core.customdev.util -> Create a class _Message_ -> Copy below code in it -> Build/Export the project to generate the .jar file. We will use this library in our testing project.

package com.sap.gateway.ip.core.customdev.util

import org.apache.camel.Exchange
import org.apache.camel.TypeConversionException

class Message {
    Exchange exchange
    Object msgBody
    Map<String, Object> msgHeaders
    Map<String, Object> msgProps
    Message(Exchange exchange) {
        this.exchange = exchange
    }

    def <Klass> Klass getBody(Class<Klass> klass)
            throws TypeConversionException {
        def body = this.exchange.getIn().getBody(klass)
        return body ?: null
    }
    Object getBody() {
        return this.msgBody
    }
    void setBody(Object msgBody) {
        this.msgBody = msgBody
    }
    Map<String, Object> getHeaders() {
        return this.msgHeaders
    }

    def <Klass> Klass getHeader(String name, Class<Klass> klass)
            throws TypeConversionException {
        if (!this.exchange.getIn().getHeader(name)) {
            return null
        } else {
            def header = this.exchange.getIn().getHeader(name, klass)
            return header ?: null
        }
    }
    void setHeaders(Map<String, Object> msgHeaders) {
        this.msgHeaders = msgHeaders
    }
    void setHeader(String name, Object value) {
        if (!this.msgHeaders)
            this.msgHeaders = \[:\]
        this.msgHeaders.put(name, value)
    }
    Map<String, Object> getProperties() {
        return this.msgProps
    }

    void setProperties(Map<String, Object> msgProps) {
        this.msgProps = msgProps
    }
    void setProperty(String name, Object value) {
        if (!this.msgProps)
            this.msgProps = \[:\]
        this.msgProps.put(name, value)
    }
    Object getProperty(String name) {
        return (this.msgProps) ? this.msgProps.get(name) : null
    }
}

  • Updated on 04-Feb-2024:

    Based on issue one user faced, its only apt I mention this that add below dependencies to your project:

    Below are the maven coordinates:

    org.apache.camel:camel-core:2.17.4 org.openjax.jaxb:xjc:0.8.5 org.spockframework:spock-core:1.3-groovy-2.4

Now that we have “Mocking a Camel Message” part sorted and we will see in a bit how it comes into picture. For now lets quickly go over two terms TDD (Test Driven Development) and BDD (Behavior Driven Development).

TDD vs BDD: Practical Differences for Developers

Imagine two developers building a shopping cart feature, but their dance with requirements unfolds differently.

Developer 1, the TDD master:

  • Writes a test for adding an item to the cart before touching any code.
  • Focuses on technical details like data validation and error handling.
  • Iterates rapidly, ensuring each test passes before moving on.
  • The final code might be polished and efficient, but the user experience is an afterthought.

Developer 2, the BDD enthusiast:

  • Collaborates with product managers on a “story” describing how users add items to the cart.
  • Writes scenarios like “As a shopper, I can add multiple items to my cart with different quantities.”
  • Focuses on the user’s journey and edge cases.
  • The final code might be slightly less optimized, but it seamlessly aligns with user expectations.

So, which approach wins?

  • TDD: Champions code coverage and technical rigor, ideal for complex logic or solo projects.
  • BDD: Fosters clear communication and user-centric development, perfect for collaborative projects and ensuring user satisfaction.

The real winner? Combining both!

  • Start with BDD stories to understand user needs.
  • Break down stories into TDD tests for clear implementation goals.
  • Embrace iterative development to refine both functionality and user experience.

Remember, TDD and BDD are tools, not absolutes. Choose the approach that best suits your project and team, and you’ll be tapping your feet to a rhythm of high-quality software and happy users.

As we are just working through the essentials, we will work through TDD as we aim to refine the script as it passes some tests and fails some.

Now that we know what a TDD is and how it works, lets move on to Spock Framework.

Spock and TDD

Imagine a world where building software is like solving a detective puzzle. You have clues (tests), a logical mind (TDD), and a trusty sidekick named Spock (a testing framework). Together, you piece together the answers, step-by-step, until the whole picture of clean, perfect code emerges.

Spock helps you tackle these puzzles with an awesome trick: “If, Do, Then” blocks or “Given, When, Then” blocks**.** These blocks are like the building blocks of your solution, guiding you through the puzzle piece by piece.

Lets take below simple multiplier example

class MultiplierSpec extends Specification {

    def "Multiplying two numbers should return their product"() {

        given: // Initial state
        def firstNumber = 5
        def secondNumber = 3

        when: // The action we're testing
        def result = multiply(firstNumber, secondNumber)

        then: // Expected outcome
        result == 15

    }

    private int multiply(int a, int b) {
        return a \* b;
    }
}

Let’s dissect this Spock logic:

  • Given: This block sets the stage. We define the variables with initial values, like the two numbers to be multiplied.
  • When: This block performs the action we’re testing. Here, we call the multiply function with the defined numbers.
  • Then: This block asserts (compares) the expected outcome. We verify that the result matches the product of the numbers.

These blocks create a clear narrative for your test, mimicking the logical flow of a story. It’s no coincidence that this structure aligns with Behavior Driven Development (BDD), which emphasizes specifying tests from the perspective of how the code should behave.

To ensure our transformation script handles all scenarios, we’ll create multiple test blocks using different input payloads. Each block will compare the generated output against a corresponding pre-defined reference payload, identifying any mismatch as an error.

Groovy Script Testing with Spock

Now lets bring our focus back to teting groovy scripts in our IDE.

For this we need to set up a few things but first we will create a Groovy Project.

Lets Add the dependencies, below are the maven coordinates:

org.apache.camel:camel-core:2.17.4
org.openjax.jaxb:xjc:0.8.5
org.spockframework:spock-core:1.3-groovy-2.4

And the mock message JAR file we created earlier in the beginning of the blog in my case its “cpi-mock-msg”

Now we will create a folder under your project called “data” and two more directories under it “in” and “out”. “in” will contain your source XML payloads, “out” will contain your expected payloads after transformation.

In the end your project structure should look like this:

You may have noticed below two files as well. Lets introduce those:

  1. CustomerTransformation.groovy - It is the actual transformation groovy script program which will be executed to transform your source or input XMLs to generate output XMLs.
  2. SpockTestSpecification - This is a groovy class based on Spock Framework which represents the specifications through the different “scenarios” listed in the class, which we will see in a bit.

Your specification class effectively connects input payloads to the CustomerTransformation program, enabling comparison between the generated output and pre-defined payloads (located in the data/out directory). Any discrepancies will be displayed as errors in the console.

Now that we have testing basics sorted, lets go over the code for each of them.

XMLTransformation.groovy

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.xml.MarkupBuilder
import java.time.LocalDate
import java.time.format.DateTimeFormatter

def Message processData(Message message) {
    Reader reader = message.getBody(Reader)
    def Customers = new XmlSlurper().parse(reader)
    Writer writer = new StringWriter()
    def indentPrinter = new IndentPrinter(writer, '    ')
    def builder = new MarkupBuilder(indentPrinter)
    builder.UserProfiles {
        'Header' {
            'Category' Customers.Header.CustomerType.text()
            'AgeGroup' Customers.Header.AgeGroup.text()
        }
        Customers.Customer.each { customer ->
            UserProfile {
                UserID(customer.CustomerID.text())
                FullName(customer.Name.text())
                ContactDetails {
                    EmailAddress(customer.Email.text())
                    PhoneNumber(customer.Phone.text())
                }
                Location {
                    City(customer.Address.City.text())
                    PostalCode(customer.Address.ZipCode.text())
                }
            }
        }
    }
    message.setBody(writer.toString())
    return message
}

This is nothing complicated here, if you have gone through Blog 3 of this series. If you haven’t gone through that, feel free to revisit.

SpockTestSpecification

import com.sap.gateway.ip.core.customdev.util.Message
import org.apache.camel.CamelContext
import org.apache.camel.Exchange
import org.apache.camel.impl.DefaultCamelContext
import org.apache.camel.impl.DefaultExchange
import spock.lang.Shared
import spock.lang.Specification

class SpockTestSpecification extends Specification {
    @Shared Script script
    @Shared CamelContext context
    Message msg
    Exchange exchange

    def setupSpec() {
        GroovyShell shell = new GroovyShell()
        script = shell.parse(new File(
                'src/main/groovy/CustomerTransformation.groovy'))
        context = new DefaultCamelContext()
    }

    def setup() {
        exchange = new DefaultExchange(context)
        msg = new Message(exchange)
    }

    def 'Scenario 1 - CountryName is not given'() {
        given: 'the message body is initialized'
        def msgBody = new File('data/in/input01.xml')
        exchange.getIn().setBody(msgBody)
        msg.setBody(exchange.getIn().getBody())

        when: 'we execute the Groovy script'
        script.processData(msg)
        exchange.getIn().setBody(msg.getBody())

        then: 'the output message body is as expected'
        msg.getBody(String) == new File('data/out/output011.xml').text.normalize()
    }

    def 'Scenario 2 - Country Name is given'() {
        given: 'the message body and property are initialized'
        def msgBody = new File('data/in/input02.xml')
        exchange.getIn().setBody(msgBody)
        msg.setBody(exchange.getIn().getBody())

        when: 'we execute the Groovy script'
        script.processData(msg)
        exchange.getIn().setBody(msg.getBody())

        then: 'the output message body is as expected'
        msg.getBody(String) == new File('data/out/output022.xml').text.normalize()
    }

}

There are three parts to above code:

  1. Groovy Shell is initialized to parse the transformation script i.e. XMLTransformation.groovy
  2. Initialized Camel Message from mock message library we created earlier. But Camel Message doesn’t work in isolation. It needs a container i.e. Camel Exchange, which in turn needs a Camel Context to carry through the Camel routes. So, Context, Exchange, Message are inialized in order.
  3. Spock testing scenario in “Given, when, then” format, which we discussed in previous section how it works. In this context, it works as shown below:
    • Given - Initializes input msg body with input XML from /data/in directory.
    • When - Executes the CustomerTransformation.groovy program in which script transformas Message object as created in “Given” block.
    • Then - Compares the generated output with predetermined output XMLs from /data/out directory as outlined in the scenarios.

Now, lets move on actually testing our transformation program. For our testing source XML is:

<Customers>
    <Header>
        <CustomerType>Diamond</CustomerType>
        <AgeGroup>30-40</AgeGroup>
    </Header>
    <Customer>
        <CustomerID>2001</CustomerID>
        <Name>David Brown</Name>
        <Email>david.brown@example.com</Email>
        <Phone>+1-555-0404</Phone>
        <Address>
            <Street>789 Pine Road</Street>
            <City>Bakersfield</City>
            <State>California</State>
            <ZipCode>93301</ZipCode>
        </Address>
    </Customer>
    <Customer>
        <CustomerID>2002</CustomerID>
        <Name>Emily Clark</Name>
        <Email>emily.clark@example.co.uk</Email>
        <Phone>+1-555-0505</Phone>
        <Address>
            <Street>321 Maple Avenue</Street>
            <City>Madison</City>
            <State>Wisconsin</State>
            <ZipCode>53703</ZipCode>
        </Address>
    </Customer>
    <Customer>
        <CustomerID>2003</CustomerID>
        <Name>Franklin Green</Name>
        <Email>franklin.green@example.au</Email>
        <Phone>+1-555-0606</Phone>
        <Address>
            <Street>654 Elm Street</Street>
            <City>Austin</City>
            <State>Texas</State>
            <ZipCode>73301</ZipCode>
        </Address>
    </Customer>
</Customers>

And the output after transformation should be:

<UserProfiles>
    <Header>
        <Category>Diamond</Category>
        <AgeGroup>30-40</AgeGroup>
    </Header>
    <UserProfile>
        <UserID>2001</UserID>
        <FullName>David Brown</FullName>
        <ContactDetails>
            <EmailAddress>david.brown@example.com</EmailAddress>
            <PhoneNumber>+1-555-0404</PhoneNumber>
        </ContactDetails>
        <Location>
            <City>Bakersfield</City>
            <PostalCode>93301</PostalCode>
        </Location>
    </UserProfile>
    <UserProfile>
        <UserID>2002</UserID>
        <FullName>Emily Clark</FullName>
        <ContactDetails>
            <EmailAddress>emily.clark@example.co.uk</EmailAddress>
            <PhoneNumber>+1-555-0505</PhoneNumber>
        </ContactDetails>
        <Location>
            <City>Madison</City>
            <PostalCode>53703</PostalCode>
        </Location>
    </UserProfile>
    <UserProfile>
        <UserID>2003</UserID>
        <FullName>Franklin Green</FullName>
        <ContactDetails>
            <EmailAddress>franklin.green@example.au</EmailAddress>
            <PhoneNumber>+1-555-0606</PhoneNumber>
        </ContactDetails>
        <Location>
            <City>Austin</City>
            <PostalCode>73301</PostalCode>
        </Location>
    </UserProfile>
</UserProfiles>

We have one more similar set of input and output for our testing which is also used in scenarios as seen in code for Specification.

Now if we execute the Specification:

All looks neat isn’t it? No! We see one of our scenario has failed.

What could have gone wrong? In the console, click the link “”, we see this:

Okay, so it seems we expect the field “Country” in the header block which our CustomerTransformation script is not doing currently.

Note: Our first test case passed because the output file didn’t have the field “Country” in it.

Now, we will not touch the payloads, thats the whole point. We need to modify the script so that it satisfies both the scenarios.

Here is the updated script, we just need to add this:

Now all should be okay. Right? Lets see if that is the case. Lets execute the specification again.

Oh, but what do we see? Now the first case has failed.

Now, if you click to see difference, this is what you see:

Problem:

It appears our program is encountering issues when attempting to generate a value for the “Country” field. If this field is absent in the source payload, we want to exclude the “Country” tag altogether in the output payload.

Solution:

To address this, we’ll focus on modifying the Transformation script exclusively, leaving the payloads intact. The goal is to ensure the “Country” field is only created in the output XML when it’s found in the corresponding source XML.

Lets replace the logic in header section for country as below:

‘Header’ { ‘Category’ Customers.Header.CustomerType.text() ‘AgeGroup’ Customers.Header.AgeGroup.text() if (Customers.Header.CountryName && !Customers.Header.CountryName.isEmpty()) { ‘Country’ Customers.Header.CountryName.text() } }

This creates a field “Country” in the output payload only if it “exists” and “is not empty” in source payload header block.

Lets execute the specification again:

Now its neat, isn’t it? Both scenarios have passed.

For those interested in replicating the script’s outcomes through CI, even though it might not be necessary, it’s a breeze! Just copy the script (assuming no external dependencies) and paste it into your cloud integration platform for a simulated run.

To adequately test data transformation, ensure your input and output combinations address every possible test case. Iterate on the transformation program until it can successfully handle all cases. The only exception is if certain cases are intentionally designed to fail for negative testing purposes.

Whats next?

And just like that, we’ve crossed the finish line of our introductory series on Groovy Scripting and Testing! I sincerely hope you found it informative and insightful. While delving into TPM-specific library usage can further expand your knowledge, the foundation you’ve gained here will make comprehension and application much smoother.

Your engagement throughout this series is really appreciated. If at any point I unintentionally omitted or conveyed inaccurate information, please don’t hesitate to share your feedback in the comments. It’s invaluable for refining future content.

Until we meet again in my next blog series, take care!