Chapter 2. Testing Camel K locally and on cloud infrastructure This chapter describes the steps to test a Camel K integration with YAKS, both locally and on the cloud infrastructure (Kubernetes platform). Section 2.1, "Testing Camel K with YAKS" Section 2.1.6, "Apache Camel K steps" Section 2.1.7, "Kamelet steps" Section 2.1.8, "Pipe steps" 2.1. Testing Camel K with YAKS 2.1.1. What is YAKS? YAKS is an Open Source test automation platform that leverages Behavior Driven Development concepts for running tests locally and on Cloud infrastructure (For example: Kubernetes or OpenShift ). This means that the testing tool is able to run your tests both as local tests and natively on Kubernetes. The framework is specifically designed to verify Serverless and Microservice applications and aims for integration testing with the application under test, up and running in a production-like environment. A typical YAKS test uses the same infrastructure as the application under test and exchanges data/events over different messaging transports (For example: Http REST, Knative eventing, Kafka, JMS and many more). As YAKS itself is written in Java the runtime uses a Java virtual machine with build tools such as Maven and integrates with well known Java testing frameworks such as JUnit , Cucumber and Citrus to run the tests. 2.1.2. Understanding the Camel K example Here is a sample Camel K integration that we like to test in the following. The integration exposes a Http service to the user. The service accepts client Http POST requests that add fruit model objects. The Camel K route applies content based routing to store the fruits in different AWS S3 buckets. In the test scenario YAKS is going to invoke the Camel K service and verify that the message content has been sent to the right AWS S3 bucket. Here is a sample fruit model object that is subject to be stored in AWS S3: { "id": 1000, "name": "Pineapple", "category":{ "id": "1", "name":"tropical" }, "nutrition":{ "calories": 50, "sugar": 9 }, "status": "AVAILABLE", "price": 1.59, "tags": ["sweet"] } Here is the Camel K integration route: from('platform-http:/fruits') .log('received fruit USD{body}') .unmarshal().json() .removeHeaders("*") .setHeader("CamelAwsS3Key", constant("fruit.json")) .choice() .when().simple('USD{body[nutrition][sugar]} <= 5') .setHeader("CamelAwsS3BucketName", constant("low-sugar")) .when().simple('USD{body[nutrition][sugar]} > 5 && USD{body[nutrition][sugar]} <= 10') .setHeader("CamelAwsS3BucketName", constant("medium-sugar")) .otherwise() .setHeader("CamelAwsS3BucketName", constant("high-sugar")) .end() .marshal().json() .log('sending USD{body}') .to("aws2-s3://noop?USDparameters") The route uses content based routing EAP based on the nutrition sugar rating of a given fruit in order to send the fruits to different AWS S3 buckets (low-sugar, medium-sugar, high-sugar). In the following the test case for this integration needs to invoke the exposed service with different fruits and verify its outcome on AWS S3. 2.1.3. How to test locally with YAKS In the beginning, let us just write the test and run it locally. For now, we do not care how to deploy the application under test in the Cloud infrastructure as everything is running on the local machine using JBang . JBang is a fantastic way to just start coding and running Java code and also Camel K integrations (also, see this former blog post about how JBang integrates with Camel K ). YAKS as a framework brings a set of ready-to-use domain specific languages (XML, YAML, Groovy, BDD Cucumber steps) for writing tests to verify your deployed services. This post uses the Behavior Driven Development integration via Cucumber. So the YAKS test is a single feature file that uses BDD Gherkin syntax like this: Feature: Camel K Fruit Store Background: Given URL: http://localhost:8080 Scenario: Create infrastructure # Start AWS S3 container Given Enable service S3 Given start LocalStack container # Create Camel K integration Given Camel K integration property file aws-s3-credentials.properties When load Camel K integration fruit-service.groovy Then Camel K integration fruit-service should print Started route1 (platform-http:///fruits) Scenario: Verify fruit service # Invoke Camel K service Given HTTP request body: yaks:readFile('pineapple.json') And HTTP request header Content-Type="application/json" When send POST /fruits Then receive HTTP 200 OK # Verify uploaded S3 file Given New global Camel context Given load to Camel registry amazonS3Client.groovy Given Camel exchange message header CamelAwsS3Key="fruit.json" Given receive Camel exchange from("aws2-s3://medium-sugar?amazonS3Client=#amazonS3Client&deleteAfterRead=true") with body: yaks:readFile('pineapple.json') Let us walk through the test step by step. Firstly, the feature file uses the usual Given-When-Then BDD syntax to give context, describe the actions and verify the outcome. Each step calls a specific YAKS action that is provided out of the box by the framework. The user is able to choose from a huge set of steps that automatically perform actions like sending/receiving Http requests/responses, starting Testcontainers , running Camel routes, connecting to a database, publishing events on Kafka or Knative brokers and many more. In the first scenario the test automatically prepares some required infrastructure. The YAKS test starts a Localstack Testcontainer to have an AWS S3 test instance running ( Given start LocalStack container ). Then the test loads and starts the Camel K integration under test ( When load Camel K integration fruit-service.groovy ) and waits for it to properly start. In local testing this step starts the Camel K integration using JBang. Later the post will also run the test in a Kubernetes environment. Now the infrastructure is up and running and the test is able to load the fruit model object as Http request body ( Given HTTP request body: yaks:readFile('pineapple.json') ) and invoke the Camel K service ( When send POST /fruits ). The test waits for the Http response and verifies its 200 OK status. In the last step, the test verifies that the fruit object has been added to the right AWS S3 bucket (medium-sugar). As YAKS itself is not able to connect to AWS S3 the test uses Apache Camel for this step. The test creates a Camel context, loads a AWS client and connects to AWS S3 with a temporary Camel route ( Given receive Camel exchange from("aws2-s3://medium-sugar?amazonS3Client=#amazonS3Client&deleteAfterRead=true") ). With this Apache Camel integration YAKS is able to use the complete 300+ Camel components for sending and receiving messages to various messaging transports. The Camel exchange body must be the same fruit model object ( yaks:readFile('pineapple.json' ) as posted in the initial Http request. YAKS uses the powerful message payload validation capabilities provided by Citrus for this message content verification. The validation is able to compare message contents of type XML, Json, plaintext and many more. This completes the test case. You can now run this test with Cucumber and JUnit for instance. The easiest way though to directly run tests with YAKS is to use the YAKS command line client . You need not set up a whole project with Maven dependencies and so on. Just write the test file and run with: USD yaks run fruit-service.feature --local You should see some log output like this: 2.1.4. Running YAKS in the Cloud YAKS is able to run tests both locally and as part of a Kubernetes cluster. When running tests on Cloud infrastructure YAKS leverages the Operator SDK and provides a specific operator to manage the test case resources on the cluster. Each time you declare a test in the form of a custom resource , the YAKS operator automatically takes care of preparing the proper runtime in order to execute the test as a Kubernetes Pod. Why would you want to run tests as Cloud-native resources on the Kubernetes platform? Kubernetes has become a standard target platform for Serverless and Microservices architectures. Writing a Serverless or Microservices application for instance with Camel K is very declarative. As a developer you just write the Camel route and run it as an integration via the Camel K operator directly on the cluster. The declarative approach as well as the nature of Serverless applications make us rely on a given runtime infrastructure, and it is essential to verify the applications also on that infrastructure. So it is only natural to also move the verifying tests into this very same Cloud infrastructure. This is why YAKS also brings your tests to the Cloud infrastructure for integration and end-to-end testing. So here is how it works. You are able to run the very same YAKS test that has been run locally also as a Pod in Kubernetes. YAKS provides a Kubernetes operator and a set of CRDs (custom resources) that we need to install on the cluster. The best way to install YAKS is to use the OperatorHub or the yaks CLI tools that you can download from the YAKS GitHub release pages . With the yaks-client binary simply run this install command: USD yaks install This command prepares your Kubernetes cluster for running tests with YAKS. It will take care of installing the YAKS custom resource definitions, setting up role permissions and creating the YAKS operator in a global operator namespace. Important You need to be a cluster admin to install custom resource definitions. The operation needs to be done only once for the entire cluster. Now that the YAKS operator is up and running you can run the very same test from local testing also on the Cloud infrastructure. The only thing that needs to be done is to adjust the Http endpoint URL of the Camel K integration from http://localhost:8080 to http://fruit-service.USD{YAKS_NAMESPACE } USD yaks run fruit-service.feature Note We have just skipped the --local CLI option. Instead of using local JBang tooling to run the test locally now the YAKS CLI connects to the Kubernetes cluster to create the test as a custom resource. From there the YAKS operator takes over preparing the test runtime and running the test as a Pod. The test did prepare some infrastructure, in particular the Camel K integration and the AWS S3 Localstack Testcontainer instance. How does that work inside Kubernetes? YAKS completely takes care of it. The Camel K integration is run with the Camel K operator running on the same Kubernetes cluster. And the Testcontainer AWS S3 instance is automatically run as a Pod in Kubernetes. Even connection settings are handled automatically. It just works! You will see some similar test log output when running the test remotely and the test performs its actions and its validation exactly the same as locally. You can also review the test Pod outcome with: USD yaks ls This is an example output you should get: 2.1.5. Demostration The whole demo code is available on this GitHub repository . It also shows how to integrate the tests in a GitHub CI actions workflow , so you can run the tests automatically with every code change. 2.1.6. Apache Camel K steps Apache Camel K is a lightweight integration framework built from Apache Camel that runs natively on Kubernetes and is specifically designed for serverless and microservice architectures. Users of Camel K can instantly run integration code written in Camel DSL on their preferred cloud (Kubernetes or OpenShift). If the subject under test is a Camel K integration, you can leverage the YAKS Camel K bindings that provide useful steps for managing Camel K integrations. Working with Camel K integrations Given create Camel K integration helloworld.groovy """ from('timer:tick?period=1000') .setBody().constant('Hello world from Camel K!') .to('log:info') """ Given Camel K integration helloworld is running Then Camel K integration helloworld should print Hello world from Camel K! The YAKS framework provides the Camel K extension library by default. You can create a new Camel K integration and check the status of the integration (e.g. running). The following sections describe the available Camel K steps in detail. 2.1.6.1. API version The default Camel K API version used to create and manage resources is v1 . You can overwrite this version with a environment variable set on the YAKS configuration. Overwrite Camel K API version YAKS_CAMELK_API_VERSION=v1alpha1 This sets the Camel K API version for all operations. 2.1.6.2. Create Camel K integrations @Given("^(?:create|new) Camel K integration {name}.{type}USD") Given create Camel K integration {name}.groovy """ <<Camel DSL>> """ Creates a new Camel K integration with specified route DSL. The integration is automatically started and can be referenced with its {name} in other steps. @Given("^(?:create|new) Camel K integration {name}.{type} with configuration:USD") Given create Camel K integration {name}.groovy with configuration: | dependencies | mvn:org.foo:foo:1.0,mvn:org.bar:bar:0.9 | | traits | quarkus.native=true,quarkus.enabled=true,route.enabled=true | | properties | foo.key=value,bar.key=value | | source | <<Camel DSL>> | You can add optional configurations to the Camel K integration such as dependencies, traits and properties. Source The route DSL as source for the Camel K integration. Dependencies List of Maven coordinates that will be added to the integration runtime as a library. Traits List of trait configuration that will be added to the integration spec. Each trait configuration value must be in the format traitname.key=value . Properties List of property bindings added to the integration. Each value must be in the format key=value . 2.1.6.3. Load Camel K integrations @Given("^load Camel K integration {name}.{type}USD") Given load Camel K integration {name}.groovy Loads the file {name}.groovy as a Camel K integration. 2.1.6.4. Delete Camel K integrations @Given("^delete Camel K integration {name}USD") Given delete Camel K integration {name} Deletes the Camel K integration with given {name} . 2.1.6.5. Verify integration state A Camel K integration is run in a normal Kubernetes pod. The pod has a state and is in a phase (e.g. running, stopped). You can verify the state with an expectation. @Given("^Camel K integration {name} is running/stoppedUSD") Given Camel K integration {name} is running Checks that the Camel K integration with given {name} is in state running and that the number of replicas is > 0. The step polls the state of the integration for a given amount of attempts with a given delay between attempts. You can adjust the polling settings with: @Given Camel K resource polling configuration Given Camel K resource polling configuration | maxAttempts | 10 | | delayBetweenAttempts | 1000 | 2.1.6.6. Watch Camel K integration logs @Given("^Camel K integration {name} should print (. )USD") * Given Camel K integration {name} should print {log-message} Watches the log output of a Camel K integration and waits for given {log-message} to be present in the logs. The step polls the logs for a given amount of time. You can adjust the polling configuration with: @Given Camel K resource polling configuration Given Camel K resource polling configuration | maxAttempts | 10 | | delayBetweenAttempts | 1000 | You can also wait for a log message to not be present in the output. Just use this step: @Given("^Camel K integration {name} should not print (. )USD") * Given Camel K integration {name} should not print {log-message} You can enable YAKS to print the logs to the test log output while the test is running. The logging can be enabled/disabled with environment variable settings `YAKS_CAMELK_PRINT_POD_LOGS=true/false To see the log output in the test console logging, you must set the logging level to INFO (for example: in yaks-config.yaml ). config: runtime: settings: loggers: - name: INTEGRATION_STATUS level: INFO - name: INTEGRATION_LOGS level: INFO 2.1.6.7. Manage Camel K resources The Camel K steps are able to create resources such as integrations. By default these resources get removed automatically after the test scenario. The auto removal of Camel K resources can be turned off with the following step. @Given("^Disable auto removal of Camel K resourcesUSD") Given Disable auto removal of Camel K resources Usually this step is a Background step for all scenarios in a feature file. This way multiple scenarios can work on the very same Camel K resources and share integrations. There is also a separate step to explicitly enable the auto removal. @Given("^Enable auto removal of Camel K resourcesUSD") Given Enable auto removal of Camel K resources By default, all Camel K resources are automatically removed after each scenario. 2.1.6.7.1. Enable and disable auto removal using environment variable You can enable/disable the auto removal via environment variable settings. The environment variable is called YAKS_CAMELK_AUTO_REMOVE_RESOURCES=true/false and must be set on the yaks-config.yaml test configuration for all tests in the test suite. There is also a system property called yaks.camelk.auto.remove.resources=true/false that you must set in the yaks.properties file. 2.1.7. Kamelet steps Kamelets are a form of predefined Camel route templates implemented in Camel K. Usually a Kamelet encapsulates a certain functionality (e.g. send messages to an endpoint). Additionaly Kamelets define a set of properties that the user needs to provide when using the Kamelet. YAKS provides steps to manage Kamelets. 2.1.7.1. API version The default Kamelet API version used to create and manage resources is v1 . (You can adjust the version, for example: to v1alpha1 with the mentioned environment variable.) You can overwrite this version with a environment variable set on the YAKS configuration. Overwrite Kamelet API version YAKS_KAMELET_API_VERSION=v1 This sets the Kamelet API version for all operations. 2.1.7.2. Create Kamelets A Kamelets defines a set of properties and specifications that you can set with separate steps in your feature. Each of the following steps set a specific property on the Kamelet. Once you are done with the Kamelet specification you are able to create the Kamelet in the current namespace. Firstly, you can specify the media type of the available slots (in, out and error) in the Kamelet. @Given("^Kamelet dataType (in|out|error)(?:=| is )\"{mediaType}\"USD") Given Kamelet dataType in="{mediaType}" The Kamelet can use a title that you set with the following step. @Given("^Kamelet title \"{title}\"USD") Given Kamelet title "{title}" Each template uses an endpoint uri and defines a set of steps that get called when the Kamelet processing takes place. The following step defines a template on the current Kamelet. @Given("^Kamelet templateUSD") Given Kamelet template """ from: uri: timer:tick parameters: period: "#property:period" steps: - set-body: constant: "{{message}}" - to: "kamelet:sink" """ The template uses two properties {{message}} and {{period}} . These placeholders need to be provided by the Kamelet user. The step defines the property message in detail: @Given("^Kamelet property definition {name}USD") Given Kamelet property definition message | type | string | | required | true | | example | "hello world" | | default | "hello" | The property receives specification such as type, required and an example. In addition to the example you can set a default value for the property. In addition to using a template on the Kamelet you can add multiple sources to the Kamelet. @Given("^Kamelet source {name}.{language}USD") Given Kamelet source timer.yaml """ <<YAML>> """ The steps defined all properties and Kamelet specifications so now you are ready to create the Kamelet in the current namespace. @Given("^(?:create|new) Kamelet {name}USD") Given create Kamelet {name} The Kamelet requires a unique name . Creating a Kamelet means that a new custom resource of type Kamelet is created. As a variation you can also set the template when creating the Kamelet. @Given("^(?:create|new) Kamelet {name} with template") Given create Kamelet {name} with template """ <<YAML>> """ This creates the Kamelet in the current namespace. 2.1.7.3. Load Kamelets You can create new Kamelets by giving the complete specification in an external YAML file. The step loads the file content and creates the Kamelet in the current namespace. @Given("^load Kamelet {name}.kamelet.yamlUSD") Given load Kamelet {name}.kamelet.yaml Loads the file {name}.kamelet.yaml as a Kamelet. At the moment only kamelet.yaml source file extension is supported. 2.1.7.4. Delete Kamelets @Given("^delete Kamelet {name}USD") Given delete Kamelet {name} Deletes the Kamelet with given {name} from the current namespace. 2.1.7.5. Verify Kamelet is available @Given("^Kamelet {name} is availableUSDUSD") Given Kamelet {name} is availableUSD Verifies that the Kamelet custom resource is available in the current namespace. 2.1.8. Pipe steps You can bind a Kamelet as a source to a sink. This concept is described with Pipes. YAKS as a framework is able to create and verify Pipes in combination with Kamelets. Note Pipes are available since API version v1 in Camel K. YAKS also supports KameletBinding resources that represent the v1alpha1 equivalent to Pipes. So in case you need to work with KameletBindings you need to explicitly set the Kamelet API version to v1alpha1 (For example; via environment variable settings YAKS_KAMELET_API_VERSION ). 2.1.8.1. Create Pipes YAKS provides multiple steps that bind a Kamelet source to a sink. The pipe is going to forward all messages processed by the source to the sink. 2.1.8.1.1. Bind to Http URI @Given("^bind Kamelet {kamelet} to uri {uri}USD") Given bind Kamelet {name} to uri {uri} This defines the Pipe with the given Kamelet name as source to the given Http URI as a sink. 2.1.8.1.2. Bind to Kafka topic You can bind a Kamelet source to a Kafka topic sink. All messages will be forwarded to the topic. @Given("^bind Kamelet {kamelet} to Kafka topic {topic}USD") Given bind Kamelet {kamelet} to Kafka topic {topic} 2.1.8.1.3. Bind to Knative channel Channels are part of the eventing in Knative. Similar to topics in Kafka the channels hold messages for subscribers. @Given("^bind Kamelet {kamelet} to Knative channel {channel}USD") Given bind Kamelet {kamelet} to Knative channel {channel} Channels can be backed with different implementations. You can explicitly set the channel type to use in the pipe. @Given("^bind Kamelet {kamelet} to Knative channel {channel} of kind {kind}USD") Given bind Kamelet {kamelet} to Knative channel {channel} of kind {kind} 2.1.8.1.4. Specify source/sink properties The Pipe may need to specify properties for source and sink. These properties are defined in the Kamelet source specifications for instance. You can set properties with values in the following step: @Given("^Pipe source propertiesUSD") Given Pipe source properties | {property} | {value} | The Kamelet source that we have used in the examples above has defined a property message . So you can set the property on the pipe as follows. Given Pipe source properties | message | "Hello world" | The same approach applies to sink properties. @Given("^Pipe sink propertiesUSD") Given Pipe sink properties | {property} | {value} | 2.1.8.1.5. Create the pipe The steps have defined source and sink of the Pipe specification. Now you are ready to create the Pipe in the current namespace. @Given("^(?:create|new) Pipe {name}USD") Given create Pipe {name} The Pipe receives a unique name and uses the previously specified source and sink. Creating a Pipe means that a new custom resource of type Pipe is created in the current namespace. 2.1.8.2. Load Pipes You can create new Pipes by giving the complete specification in an external YAML file. The step loads the file content and creates the Pipe in the current namespace. @Given("^load Pipe {name}.yamlUSD") Given load Pipe {name}.yaml Loads the file {name}.yaml as a Pipe. At the moment YAKS only supports .yaml source files. 2.1.8.3. Delete Pipes @Given("^delete Pipe {name}USD") Given delete Pipe {name} Deletes the Pipe with given {name} from the current namespace. 2.1.8.4. Verify Pipe is available @Given("^Pipe {name} is availableUSDUSD") Given Pipe {name} is availableUSD Verifies that the Pipe custom resource is available in the current namespace. 2.1.8.5. Manage Kamelet and Pipe resources The described steps are able to create Kamelet resources on the current Kubernetes namespace. By default these resources get removed automatically after the test scenario. The auto removal of Kamelet resources can be turned off with the following step. @Given("^Disable auto removal of Kamelet resourcesUSD") Given Disable auto removal of Kamelet resources Usually this step is a Background step for all scenarios in a feature file. This way multiple scenarios can work on the very same Kamelet resources and share integrations. There is also a separate step to explicitly enable the auto removal. @Given("^Enable auto removal of Kamelet resourcesUSD") Given Enable auto removal of Kamelet resources By default, all Kamelet resources are automatically removed after each scenario. 2.1.8.5.1. Enable and disable auto removal using environment variable You can enable/disable the auto removal via environment variable settings. The environment variable is called YAKS_CAMELK_AUTO_REMOVE_RESOURCES=true/false and must be set on the yaks-config.yaml test configuration for all tests in the test suite. There is also a system property called yaks.camelk.auto.remove.resources=true/false that you must set in the yaks.properties file.

Commands:
{ "id": 1000, "name": "Pineapple", "category":{ "id": "1", "name":"tropical" }, "nutrition":{ "calories": 50, "sugar": 9 }, "status": "AVAILABLE", "price": 1.59, "tags": ["sweet"] }
from('platform-http:/fruits') .log('received fruit USD{body}') .unmarshal().json() .removeHeaders("*") .setHeader("CamelAwsS3Key", constant("fruit.json")) .choice() .when().simple('USD{body[nutrition][sugar]} <= 5') .setHeader("CamelAwsS3BucketName", constant("low-sugar")) .when().simple('USD{body[nutrition][sugar]} > 5 && USD{body[nutrition][sugar]} <= 10') .setHeader("CamelAwsS3BucketName", constant("medium-sugar")) .otherwise() .setHeader("CamelAwsS3BucketName", constant("high-sugar")) .end() .marshal().json() .log('sending USD{body}') .to("aws2-s3://noop?USDparameters")
Feature: Camel K Fruit Store Background: Given URL: http://localhost:8080 Scenario: Create infrastructure # Start AWS S3 container Given Enable service S3 Given start LocalStack container # Create Camel K integration Given Camel K integration property file aws-s3-credentials.properties When load Camel K integration fruit-service.groovy Then Camel K integration fruit-service should print Started route1 (platform-http:///fruits) Scenario: Verify fruit service # Invoke Camel K service Given HTTP request body: yaks:readFile('pineapple.json') And HTTP request header Content-Type="application/json" When send POST /fruits Then receive HTTP 200 OK # Verify uploaded S3 file Given New global Camel context Given load to Camel registry amazonS3Client.groovy Given Camel exchange message header CamelAwsS3Key="fruit.json" Given receive Camel exchange from("aws2-s3://medium-sugar?amazonS3Client=#amazonS3Client&deleteAfterRead=true") with body: yaks:readFile('pineapple.json')
yaks run fruit-service.feature --local
INFO | INFO | ------------------------------------------------------------------------ INFO | .__ __ INFO | ____ |__|/ |________ __ __ ______ INFO | _/ ___\| \ __\_ __ \ | \/ ___/ INFO | \ \___| || | | | \/ | /\___ INFO | \___ >__||__| |__| |____//____ > INFO | \/ \/ INFO | INFO | C I T R U S T E S T S 3.4.0 INFO | INFO | ------------------------------------------------------------------------ INFO | Scenario: Create infrastructure # fruit-service.feature:6 Given URL: http://localhost:8080 Given Enable service S3 [...] Scenario: Verify fruit service # fruit-service.feature:20 Given URL: http://localhost:8080 Given HTTP request body: yaks:readFile('pineapple.json') [...] Scenario: Remove infrastructure # fruit-service.feature:31 Given URL: http://localhost:8080 Given delete Camel K integration fruit-service Given stop LocalStack container 3 Scenarios (3 passed) 18 Steps (18 passed) 0m18,051s INFO | ------------------------------------------------------------------------ INFO | INFO | CITRUS TEST RESULTS INFO | INFO | Create infrastructure .......................................... SUCCESS INFO | Verify fruit service ........................................... SUCCESS INFO | Remove infrastructure .......................................... SUCCESS INFO | INFO | TOTAL: 3 INFO | FAILED: 0 (0.0%) INFO | SUCCESS: 3 (100.0%) INFO | INFO | ------------------------------------------------------------------------ 3 Scenarios (3 passed) 18 Steps (18 passed) 0m18,051s Test results: Total: 0, Passed: 1, Failed: 0, Errors: 0, Skipped: 0 fruit-service (fruit-service.feature): Passed
yaks install
yaks run fruit-service.feature
yaks ls
NAME PHASE TOTAL PASSED FAILED SKIPPED ERRORS fruit-service Passed 3 3 0 0 0
Given create Camel K integration helloworld.groovy """ from('timer:tick?period=1000') .setBody().constant('Hello world from Camel K!') .to('log:info') """ Given Camel K integration helloworld is running Then Camel K integration helloworld should print Hello world from Camel K!
YAKS_CAMELK_API_VERSION=v1alpha1
Given create Camel K integration {name}.groovy """ <<Camel DSL>> """
Given create Camel K integration {name}.groovy with configuration: | dependencies | mvn:org.foo:foo:1.0,mvn:org.bar:bar:0.9 | | traits | quarkus.native=true,quarkus.enabled=true,route.enabled=true | | properties | foo.key=value,bar.key=value | | source | <<Camel DSL>> |
Given load Camel K integration {name}.groovy
Given delete Camel K integration {name}
Given Camel K integration {name} is running
Given Camel K resource polling configuration | maxAttempts | 10 | | delayBetweenAttempts | 1000 |
Given Camel K integration {name} should print {log-message}
Given Camel K resource polling configuration | maxAttempts | 10 | | delayBetweenAttempts | 1000 |
Given Camel K integration {name} should not print {log-message}
Given Disable auto removal of Camel K resources
Given Enable auto removal of Camel K resources
YAKS_KAMELET_API_VERSION=v1
Given Kamelet dataType in="{mediaType}"
Given Kamelet title "{title}"
Given Kamelet template """ from: uri: timer:tick parameters: period: "#property:period" steps: - set-body: constant: "{{message}}" - to: "kamelet:sink" """
Given Kamelet property definition message | type | string | | required | true | | example | "hello world" | | default | "hello" |
Given Kamelet source timer.yaml """ <<YAML>> """
Given create Kamelet {name}
Given create Kamelet {name} with template """ <<YAML>> """
Given load Kamelet {name}.kamelet.yaml
Given delete Kamelet {name}
Given Kamelet {name} is availableUSD
Given bind Kamelet {name} to uri {uri}
Given bind Kamelet {kamelet} to Kafka topic {topic}
Given bind Kamelet {kamelet} to Knative channel {channel}
Given bind Kamelet {kamelet} to Knative channel {channel} of kind {kind}
Given Pipe source properties | {property} | {value} |
Given Pipe source properties | message | "Hello world" |
Given Pipe sink properties | {property} | {value} |
Given create Pipe {name}
Given load Pipe {name}.yaml
Given delete Pipe {name}
Given Pipe {name} is availableUSD
Given Disable auto removal of Kamelet resources
Given Enable auto removal of Kamelet resources