citrusframework / citrusframework/citrus
Groovy validation swaps expected and got when using JSON assert
- Dominant language
- Java
- Stars
- 485
- Forks
- 155
- Avg merge
- 4d 22h
- Merged PRs (30d)
- 6
Description
**Citrus Version**
groovy: 3.4.0
citrus: 3.4.0
**Question**
I have the following testing scenario :
Inbound SFTP -> Mulesoft (SUT) -> Sends message to AMQ
I need to validate if the message send to Anypoint MQ is the same as the test sample
Therefore I wrote a script that looks like this :
```groovy
.... imports
// Get Response message from context
def responseText = context.getVariable("amqResponseMessage")
def responseType = context.getVariable("amqResponseType")
// Parse message body
def responseJson = new JsonSlurper().parseText(responseText)
def actualMessageBody = responseJson[0].body
// Get Comparable file from filesystem
def filePath = context.getVariable("filePathAmqResponseMessage")
def fileContent = new File(filePath).text
Logger logger = Logger.getLogger("")
// Validate messages
switch (responseType) {
case "json":
// Validate JSON
logger.info("----- actual ----")
logger.info(actualMessageBody)
logger.info("----- expected ----")
logger.info(fileContent)
JSONAssert.assertEquals(actualMessageBody, fileContent, JSONCompareMode.STRICT)
break
}
```
When using this script in other test scenarios it works perfect but it seems that when you have the SFTP -> AMQ the expected and got, are being swapped for some reason :

**What I've tried so far**
To Debug I added the loggers for actual & expected and there each file is in the proper variable (so not swapped)
**Additional information**
Maybe update to macOs Sonoma ?
Step for receiving & validating :
```xml
```
Contributor guide
Research direction
Start with validateAMQResponseMessage.groovy and the JSONAssert.assertEquals call, then inspect the XML receive-response and extraction steps that populate amqResponseMessage. Reproduce the failure with the provided SFTP-to-AMQ scenario and compare the assertion output with the logged actualMessageBody and fileContent; done means the reported expected and actual values consistently match the supplied arguments.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- groovy, java
- Domain
- testing-qa
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100