{"type":"doc","content":[{"type":"paragraph","content":[{"type":"inlineExtension","attrs":{"extensionType":"com.atlassian.confluence.macro.core","extensionKey":"excerpt-include","parameters":{"macroParams":{"":{"value":"Task Status"},"nopanel":{"value":"true"}},"macroMetadata":{"macroId":{"value":"fedc130f-ce50-4306-8fab-a7cf878f64bd"},"schemaVersion":{"value":"1"},"title":"Insert excerpt"}},"localId":"050eddc5-23b3-40ec-9443-41d182827ecc"}}]},{"type":"paragraph","content":[{"text":"This page contains information about Service Testing, testing tools and example of usage of such tools for Service Testing.","type":"text"}]},{"type":"extension","attrs":{"layout":"default","extensionType":"com.atlassian.confluence.macro.core","extensionKey":"toc","parameters":{"macroParams":{"minLevel":{"value":"1"},"maxLevel":{"value":"6"},"outline":{"value":"true"},"style":{"value":"default"},"type":{"value":"list"},"printable":{"value":"true"}},"macroMetadata":{"macroId":{"value":"c0f67da0-e640-42b5-8385-fe2a17a90994"},"schemaVersion":{"value":"1"},"title":"Table of Contents"}},"localId":"8dfdf3b1-5206-43d3-b0ca-c42d9a236d68"}},{"type":"heading","attrs":{"level":1},"content":[{"text":"Introduction","type":"text"}]},{"type":"paragraph","content":[{"text":"Software testing is a fundamental aspect of the software development lifecycle, encompassing a range of techniques and methodologies to ensure the quality, functionality, and reliability of software products.","type":"text"},{"type":"hardBreak"},{"text":"The primary objective of testing is to identify defects or bugs in software and ensure that it meets the specified requirements. Beyond just finding errors, testing aims to validate that the software behaves as expected, performs reliably under various conditions, and delivers a seamless user experience.","type":"text"}]},{"type":"paragraph","content":[{"text":"In this document, we provide:","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"an overview of usual test categories (and how they are structured)","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"an introduction to API Testing","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"a set of API Testing tools that, through a survey performed in the SWIM CoIs, are known to be mostly used among the participants to such CoIs. Tools are grouped on the basis of the Yellow Profile Binding(s) that they more easily support (as a single tool may support more “bindings”)","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"whenever possible, concrete examples of the usage/configuration of such tools for testing of SWIM Services","type":"text"}]}]}]},{"type":"heading","attrs":{"level":1},"content":[{"text":"Testing layers","type":"text"}]},{"type":"paragraph","content":[{"text":"Software testing is a critical aspect of the development process, ensuring that applications meet quality standards, perform as expected, and deliver a seamless user experience. Testing is usually structured into layers, each focusing on specific aspects and depths of the application’s functionality.","type":"text"},{"type":"hardBreak"},{"text":"Testing layers are designed to systematically validate different levels of software components, from small units of code to the entire system. Each layer plays a vital role in identifying and rectifying defects at different stages of development. By employing a layered testing approach, we can detect issues early, reduce bugs, and enhance the overall stability and reliability of the software.","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Testing pyramid","type":"text"}]},{"type":"paragraph","content":[{"text":"The testing pyramid is a visual representation that advocates a balanced testing strategy by emphasizing the distribution of tests across different levels. At the base of the pyramid are the foundational unit tests, forming the majority of the tests due to their speed, granularity, and focus on individual code units. Moving upward, integration tests follow, verifying interactions between components. Finally, at the apex, sit the higher-level sub-system and system tests, which are fewer in number due to their complexity and slower execution. The pyramid encourages prioritizing more low-level tests, ensuring a solid foundation of thoroughly tested code, while progressively fewer high-level tests validate system-wide functionality. White-filled layers are indicating tests using “white-box” approach (i.e. tests that have access to the internals of the application), while black-filled layers are indicating tests using the “black-box” approach (i.e. tests that examines the functionality of the application without peering into its internal structures or workings).","type":"text"}]},{"type":"paragraph"},{"type":"mediaSingle","attrs":{"layout":"center","width":385,"widthType":"pixel"},"content":[{"type":"media","attrs":{"width":315,"alt":"Testing Pyramid2.png","id":"eb5c6bbc-9ac5-439c-8d38-7e423819765b","collection":"contentId-128385362","type":"file","height":243}},{"type":"caption","content":[{"text":"Testing pyramid","type":"text"}]}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Overview of testing layers","type":"text"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Unit Tests","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Scope","type":"text","marks":[{"type":"strong"}]},{"text":": Tests small units of code, such as individual functions, methods, or classes.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Objective","type":"text","marks":[{"type":"strong"}]},{"text":": Verify isolated functionality of each unit.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Approach","type":"text","marks":[{"type":"strong"}]},{"text":": Utilizes mocking to isolate units from dependencies.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Timing","type":"text","marks":[{"type":"strong"}]},{"text":": Conducted pre-build to ensure basic functionality and correctness at the code level.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Automated","type":"text","marks":[{"type":"strong"}]},{"text":": Always automated","type":"text"}]}]}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Integration","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Scope","type":"text","marks":[{"type":"strong"}]},{"text":": Examines interaction between different units or systems to test integration.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Objective","type":"text","marks":[{"type":"strong"}]},{"text":": Verify interaction collaboration and communication between components.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Approach","type":"text","marks":[{"type":"strong"}]},{"text":": May include all types of parts included in the application under test, like database or message broker.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Timing","type":"text","marks":[{"type":"strong"}]},{"text":": Executed pre-build to ensure seamless interaction between components.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Automated","type":"text","marks":[{"type":"strong"}]},{"text":": Always automated","type":"text"}]}]}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Sub-system","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Scope","type":"text","marks":[{"type":"strong"}]},{"text":": Focuses on testing individual sub-systems (e.g. microservices).","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Objective","type":"text","marks":[{"type":"strong"}]},{"text":": Verify functionality and behavior within the sub-system (e.g. a microservice’s container) or runtime environment.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Approach","type":"text","marks":[{"type":"strong"}]},{"text":": Tests sub-system’s interface, assessing functionalities with or without external dependencies.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Timing","type":"text","marks":[{"type":"strong"}]},{"text":": Conducted after build (e.g. containerization) of the sub-system.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Automated","type":"text","marks":[{"type":"strong"}]},{"text":": Preferred to be automated, but may be manual","type":"text"}]}]}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"System","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Scope","type":"text","marks":[{"type":"strong"}]},{"text":": Tests the entire system by integrating multiple sub-systems (e.g. microservices) and external systems.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Objective","type":"text","marks":[{"type":"strong"}]},{"text":": Ensures proper collaboration and functioning of interconnected sub-systems and external systems.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Approach","type":"text","marks":[{"type":"strong"}]},{"text":": Verifies end-to-end scenarios and interactions between multiple sub-systems and external systems.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Timing","type":"text","marks":[{"type":"strong"}]},{"text":": Performed after individual sub-system and external system are tested and integrated, validating overall system functionality. Might include acceptance test where stakeholders validate correct behavior of delivered solution.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Automated","type":"text","marks":[{"type":"strong"}]},{"text":": Preferred to be automated, but may be manual","type":"text"}]}]}]},{"type":"heading","attrs":{"level":1},"content":[{"text":"API Testing","type":"text"}]},{"type":"paragraph","content":[{"text":"API (or, more generically, Service) Testing involves verifying the functionality, reliability, security, and performance of APIs. It ensures that APIs work as expected, handle various inputs, and produce accurate outputs. Depending on the needs, it may address several aspects:","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Functional Testing: Validates whether the API behaves correctly according to its specifications.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Security Testing: Ensures that APIs are secure against unauthorized access and data breaches.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Performance Testing: Measures response times, throughput, and scalability.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Validation: Verifies that APIs adhere to standards and meet business requirements.","type":"text"}]}]}]},{"type":"paragraph","content":[{"text":"With respect to the previous categorization, API Testing can be considered applicable both at Microservice level (as microservices expose APIs) and at System level since Services APIs may require (from a Service Provider perspective) contributions from several components/microservices within a System. ","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"API Testing and Validation Tools","type":"text"}]},{"type":"paragraph","content":[{"text":"Several tools facilitating API Testing are available on the market. Each one may have its own specificities and functionalities (e.g. support different programming languages for writing test cases, different support for test automation etc…) and/or be able to test specific kinds of services – e.g. only HTTP based, or SOAP and HTTP based services….","type":"text"}]},{"type":"paragraph","content":[{"text":"In the following, some example of tools which are often used by aviation stakeholders are provided based on their capability to support API testing depending on the YP Bindings.","type":"text"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"SOAP-Based Web Services (YP SOAP Bindings)","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"SoapUI","type":"text","marks":[{"type":"link","attrs":{"href":"https://www.soapui.org/"}}]}]},{"type":"paragraph","content":[{"text":"SoapUI allows you to create and execute functional tests for SOAP services. You can define test cases, input parameters, and expected results. It also supports load testing, simulating multiple concurrent users to assess performance. It provides built-in assertions to validate responses (e.g., XPath, JSONPath) and it is possible to automate test execution using Groovy scripts.","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Languages Supported: Java, Groovy","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Licensing Model: SoapUI Community (open-source) and SoapUI Pro (commercial).","type":"text"}]}]}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Citrus Framework","type":"text","marks":[{"type":"link","attrs":{"href":"https://citrusframework.org/"}}]}]},{"type":"paragraph","content":[{"text":"Citrus allows writing tests in a ","type":"text"},{"text":"Behavior-Driven Development (BDD)","type":"text","marks":[{"type":"link","attrs":{"href":"https://en.wikipedia.org/wiki/Behavior-driven_development"}}]},{"text":" style, making scenarios more readable. It supports end-to-end testing for both SOAP and REST services and easily integrates with Spring-based applications. It also supports data-driven testing using external data sources.","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Languages Supported: Java","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Licensing Model: Open-source.","type":"text"}]}]}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"JMeter","type":"text","marks":[{"type":"link","attrs":{"href":"https://jmeter.apache.org/"}}]}]},{"type":"paragraph","content":[{"text":"Originally designed for load testing, JMeter can also be used for functional testing. It supports both SOAP and REST protocols. It allows scripting test scenarios and automating test execution while providing assertions for validating responses.","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Languages Supported: Java","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Licensing Model: Open-source.","type":"text"}]}]}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"REST-Based Services (YP WS Light Binding)","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Postman","type":"text","marks":[{"type":"link","attrs":{"href":"https://www.postman.com/"}}]}]},{"type":"paragraph","content":[{"text":"Postman offers an intuitive interface for creating and managing API tests. It allows to easily create requests (GET, POST, etc.) and set headers, parameters, and authentication. It allows to validate response data using built-in assertions. It allows teams to collaborate on “collections” (i.e. a group of test cases) and share test suites. It also allows scripting for automation.","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Languages Supported: JavaScript","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Licensing Model: Freemium (free with paid options)","type":"text"}]}]}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"JMeter","type":"text","marks":[{"type":"link","attrs":{"href":"https://jmeter.apache.org/"}}]}]},{"type":"paragraph","content":[{"text":"Refer to the characteristics mentioned earlier.","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Swagger.io","type":"text","marks":[{"type":"link","attrs":{"href":"http://Swagger.io"}}]}]},{"type":"paragraph","content":[{"text":"Swagger helps design, document, and test REST APIs. It generates interactive API documentation but can also be used to automatically generates client SDKs from API definitions. It is mostly useful during early stages of testing (e.g. for simple unit tests or simple tests during development) not for creation of more comprehensive test cases and/or test automation.","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Languages Supported: N/A (web-based tool)","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Licensing Model: Open-source.","type":"text"}]}]}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Asynchronous Services (YP AMQP Binding)","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Karate DSL","type":"text","marks":[{"type":"link","attrs":{"href":"https://www.karatelabs.io/"}}]}]},{"type":"paragraph","content":[{"text":"Karate DSL supports ","type":"text"},{"text":"behavior-driven (BDD) testing","type":"text","marks":[{"type":"link","attrs":{"href":"https://en.wikipedia.org/wiki/Behavior-driven_development"}}]},{"text":" for REST and AMQP services. It allows parallel execution of test scenarios. As for BDD test writing style, test scenarios are written in plain English (","type":"text"},{"text":"Gherkin ","type":"text","marks":[{"type":"link","attrs":{"href":"https://cucumber.io/docs/gherkin/reference/"}}]},{"text":"syntax). Karate allows to automatically generate test reports.","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Languages Supported: Built on top of Cucumber (Gherkin syntax)","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Licensing Model: Open-source.","type":"text"}]}]}]},{"type":"heading","attrs":{"level":1},"content":[{"text":"API Testing Examples","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Karate DSL - Testing an implementation of EUROCAE ED254 Arrival Sequence Service Performance Standard","type":"text"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"ED254 Arrival Sequence Service - Overview","type":"text"}]},{"type":"paragraph","content":[{"text":"In order to optimize inbound traffic flows at major hubs, arrival flights will be managed well before the top of descent. The consequence is that metering and sequencing activities need to be shared between several ATS units and will start in the En-Route phase when flights are cruising.","type":"text"}]},{"type":"paragraph","content":[{"text":"This will allow absorbing tactical delay in line at a much higher altitude than the current holding or radar vectoring within the TMAs, and thus saving fuel and reducing CO2 emissions for Airspace Users.","type":"text"}]},{"type":"paragraph","content":[{"text":"When an Arrival Manager (AMAN) is available at an airport, its horizon is at present usually limited to the geographical scope of the terminal control center. It is implicating that the view is not always time symmetrical from the runway and somehow blind at what's happening further out.","type":"text"}]},{"type":"paragraph","content":[{"text":"These shortfalls will be overcome by:","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Expanding the planning horizon of AMAN systems up to 200NM in order to include the economical Top of Descent (ToD).","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Providing Upstream ATS units with Arrival Management Information and so allowing cross border (be it system border, ATS unit border, ANSP border, State or Regional organization border) activities.","type":"text"}]}]}]},{"type":"paragraph","content":[{"text":"The provision of Arrival Information from Downstream ATSU to Upstream ATSU is communicated via SWIM for the pre-sequencing of the arrival stream.","type":"text"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Arrival Sequence Service - Conceptual Architecture","type":"text"}]},{"type":"paragraph","content":[{"text":"From an high level perspective, the Arrival Sequence Service is based on a ","type":"text"},{"text":"“Publish/Subscribe Push” Message Exchange Pattern","type":"text","marks":[{"type":"link","attrs":{"href":"https://reference.swim.aero/technical-infrastructure/guidance-for-pub-sub-push-implementation.html"}}]},{"text":". ","type":"text"}]},{"type":"paragraph","content":[{"text":"Service Consumers are expected to inform the Service Provider about their interest to receive updates of the Arrival Sequence for a given (destination) Airport by subscribing to the Service (via ","type":"text"},{"text":"Synchronous Request/Reply","type":"text","marks":[{"type":"link","attrs":{"href":"https://reference.swim.aero/technical-infrastructure/message-exchange-patterns-identification-guidelines.html"}}]},{"text":"). Upon subscription, Consumers may provide filtering conditions that affect the content of the “Arrival Sequence” message (e.g. asking to receive sequence “entries” only related to a given Airline). ","type":"text"}]},{"type":"paragraph","content":[{"text":"According to the ED254 Specification, the Service Provider evaluates (at least every 30 seconds) if the content of the Arrival Sequence differs from the last distribution. In such a case, the updated message will be distributed, otherwise distribution may be omitted.","type":"text"}]},{"type":"paragraph","content":[{"text":"Message distribution can be performed either via WS-Notification or AMQP Binding (AMQP being preferred).","type":"text"}]},{"type":"paragraph","content":[{"text":"Therefore, from an high level perspective, the conceptual architecture can be depicted as follows: ","type":"text"}]},{"type":"mediaSingle","attrs":{"layout":"center","width":356,"widthType":"pixel"},"content":[{"type":"media","attrs":{"width":356,"alt":"ED254.PNG","id":"6cb0259e-c42c-45ff-9aaa-ded6b6f7caee","collection":"contentId-128385362","type":"file","height":182}}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Testing filtering feature with Karate DSL","type":"text"}]},{"type":"paragraph","content":[{"text":"In the following, it is considered that the service interfaces use REST (i.e. “WS Light Binding” - in terms of Yellow Profile Specification) for synchronous request/reply and AMQP for publish/subscribe push.","type":"text"}]},{"type":"paragraph","content":[{"text":"The code bellow will show an example test for the filtering feature in ED254. ","type":"text"}]},{"type":"paragraph","content":[{"text":"It contains a “feature” file, java Queueconsumer file and a junit test file.","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Feature file","type":"text"}]},{"type":"paragraph","content":[{"text":"Here is the test file that will execute the test. It is written using ","type":"text"},{"text":"Gherkin ","type":"text","marks":[{"type":"link","attrs":{"href":"https://cucumber.io/docs/gherkin/reference/"}}]},{"text":"which is used by other frameworks like ","type":"text"},{"text":"Cucumber ","type":"text","marks":[{"type":"link","attrs":{"href":"https://cucumber.io/"}}]},{"text":"and makes use of the Given, When, Then to make test cases. Our test will:","type":"text"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Make sure application is up and healthy","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Make a subscription request with a filter","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Assert that we only get expected messages","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Clean up subscription and queue connection","type":"text"}]}]}]},{"type":"codeBlock","content":[{"text":"Feature: ED254 - EAMAN Provider Gateway filtration tests\n \n Background:\n * def QueueConsumer = Java.type('test.integration.utils.QueueConsumer')\n \n # Function to get all messages\n * def getAerodromeDesignator = function(msg){ return karate.xmlPath(msg, '/arrivalSequence/aerodromeDesignator') }\n \n Scenario: filtering one aerodrome\n # Make sure Application is up and healthy\n Given url http://localhost:9000\n And path '/actuator/health'\n When method get\n * print response\n Then match response contains {'status':'UP'}\n \n # Execute test\n # ArrivalSequencePublisher interface: Create subscription\n Given url http://localhost:8080\n And path '/arrivalSequenceInformation/v1/subscriptions'\n And request '\"subscriptionFilters\": { \"destinationAerodrome\": [{ \"aerodromeDesignator\": \"ESSA\" }] }'\n When method post\n * print response\n Then status 201\n # Save subscription reference to unsubscribe later\n And def subscriptionRef = response.subscriptionReference\n \n # ArrivalSequenceSubscriber interface: Assert AMAN messages\n Given def queue = new QueueConsumer(\"user1_queue\", \"tcp://localhost:61616\",\n \"user1\", \"pass\");\n When def messages = queue.waitUntilCount(1)\n And def aerodromeDesignators = karate.map(messages, getAerodromeDesignator)\n Then match karate.xmlPath(messages[0], '/arrivalSequence/aerodromeDesignator') ==\n 'ESSA'\n And match messages[0] count(/arrivalSequence//arrivalManagementInformation) == 5\n And match karate.xmlPath(messages[0], '/arrivalSequence//arcid') contains\n [\"SAS88R\",\"SZS898\",\"NOZ812\",\"NSZ2ES\",\"DLH802\"]\n \n # Clean up, unsubscribe and close AMQP queue connection\n Given url http://localhost:8080\n And path '/arrivalSequenceInformation/v1/subscriptions'\n And param subscriptionReference = subscriptionRef\n When method delete\n Then status 200\n And print response\n And queue.close();","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"QueueConsumer.java File","type":"text"}]},{"type":"paragraph","content":[{"text":"Karate comes with built in support for HTTP functions like url, path, param, method and status. But it does not come with support for queues and topics but it does support Java classes. So we can implment our own class that handles the messages.","type":"text"}]},{"type":"codeBlock","attrs":{"language":"java"},"content":[{"text":"package test.integration.utils;\n\nimport java.util.ArrayList;\nimport java.util.List;\nimport java.util.Map;\nimport java.util.concurrent.CompletableFuture;\nimport java.util.concurrent.TimeUnit;\nimport java.util.function.Predicate;\nimport java.util.stream.Collectors;\nimport org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;\nimport jakarta.jms.Connection;\nimport jakarta.jms.ConnectionFactory;\nimport jakarta.jms.Destination;\nimport jakarta.jms.JMSException;\nimport jakarta.jms.MessageConsumer;\nimport jakarta.jms.Queue;\nimport jakarta.jms.Session;\nimport jakarta.jms.TextMessage;\nimport lombok.extern.log4j.Log4j2;\n\n@Log4j2\npublic class QueueConsumer {\n private Connection connection = null;\n private final MessageConsumer consumer;\n private final Session session;\n private final List messages = new ArrayList<>();\n private CompletableFuture

Browser not supported