From e0141042c3de8e0b2a46cdce59b6a323ad871bf9 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Mon, 9 Oct 2023 10:53:31 -0700 Subject: [PATCH 01/53] interim --- modules/ROOT/nav.adoc | 13 + modules/ROOT/pages/connectivity-testing.adoc | 79 +++ modules/ROOT/pages/metadata-testing.adoc | 244 ++++++++ modules/ROOT/pages/mtf-expecting-errors.adoc | 78 +++ modules/ROOT/pages/mtf-metadata-testing.adoc | 138 +++++ .../ROOT/pages/mtf-parameterized-tests.adoc | 105 ++++ modules/ROOT/pages/mtf-testing-examples.adoc | 17 + modules/ROOT/pages/mtf-testing-sources.adoc | 120 ++++ .../ROOT/pages/mtf-using-test-classes.adoc | 78 +++ ...extensions-maven-plugin-configuration.adoc | 577 ++++++++++++++++++ .../pages/munit-extensions-maven-plugin.adoc | 95 +++ modules/ROOT/pages/testing-oauth-modules.adoc | 77 +++ ...testing-writing-your-first-munit-test.adoc | 196 ++++++ modules/ROOT/pages/testing2.adoc | 24 + 14 files changed, 1841 insertions(+) create mode 100644 modules/ROOT/pages/connectivity-testing.adoc create mode 100644 modules/ROOT/pages/metadata-testing.adoc create mode 100644 modules/ROOT/pages/mtf-expecting-errors.adoc create mode 100644 modules/ROOT/pages/mtf-metadata-testing.adoc create mode 100644 modules/ROOT/pages/mtf-parameterized-tests.adoc create mode 100644 modules/ROOT/pages/mtf-testing-examples.adoc create mode 100644 modules/ROOT/pages/mtf-testing-sources.adoc create mode 100644 modules/ROOT/pages/mtf-using-test-classes.adoc create mode 100644 modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc create mode 100644 modules/ROOT/pages/munit-extensions-maven-plugin.adoc create mode 100644 modules/ROOT/pages/testing-oauth-modules.adoc create mode 100644 modules/ROOT/pages/testing-writing-your-first-munit-test.adoc create mode 100644 modules/ROOT/pages/testing2.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 56492074..073a6b7a 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -84,3 +84,16 @@ ** xref:validators.adoc[Validators with Mule SDK] ** xref:dmt.adoc[DevKit to SDK Migration Tool] * xref:xml-sdk.adoc[XML SDK] +* xref:testing2.adoc[MTF] + ** xref:testing-writing-your-first-munit-test.adoc[Writing Your First MUnit Test] + ** xref:mtf-testing-examples.adoc[SDK Testing Examples] + *** xref:mtf-expecting-errors.adoc[Expecting Errors] + *** xref:mtf-metadata-testing.adoc[Metadata Testing Examples] + *** xref:mtf-parameterized-tests.adoc[Parameterized Test] + *** xref:mtf-testing-sources.adoc[Testing Sources] + *** xref:mtf-using-test-classes.adoc[Using Test Classes] + *** xref:testing-oauth-modules.adoc[Testing OAuth Enabled Connectors] + ** xref:munit-extensions-maven-plugin.adoc[Operating the MUnit Extensions Maven Plugin] + ** xref:munit-extensions-maven-plugin-configuration.adoc[MUnit Extensions Maven Plugin Configuration] + ** xref:metadata-testing.adoc[Metadata Testing] + ** xref:connectivity-testing.adoc[Connectivity Testing] diff --git a/modules/ROOT/pages/connectivity-testing.adoc b/modules/ROOT/pages/connectivity-testing.adoc new file mode 100644 index 00000000..07ce103c --- /dev/null +++ b/modules/ROOT/pages/connectivity-testing.adoc @@ -0,0 +1,79 @@ +== Connectivity Testing +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +== Prerequisites + +* Be familiar with how to define a connection for your module. + +See xref:connections.adoc[Connections] for more information. +* To create connectivity tests, add the `mtf-tools` dependency to your project: ++ +[source,xml,linenums] +---- + + com.mulesoft.munit + mtf-tools + 1.0.0 + mule-plugin + test + +---- +* Connectivity Testing is available since Mule Runtime version 4.2.0. + +If your connector has a minMuleVersion prior to 4.2.0, add the `minMuleVersion` to your connectivity testing suite: `` + + +== Test Connectivity + +The `test-connectivity` processor establishes a connection using the given configuration. If testing connectivity with the given configuration fails, the processor will fail with the proper exception, description +and error type (if present), + +=== Successful Connection + +When you test that a connection is valid, you are validating that the processor does not fail. A successful connection test looks as follows: + +.Valid connection +[source,xml,linenums] +---- + + + + + +---- + +=== Invalid connection + +When a connection fails, the processor fails. Therefore, to test an invalid connection, expect the error in the test: + +.Invalid connection +[source,xml,linenums] +---- + + + + + +---- + +If the connection fails with an error type, you can expect it as well: + +.Invalid connection with error type +[source,xml,linenums] +---- + + + + + +---- + + + +== See Also + diff --git a/modules/ROOT/pages/metadata-testing.adoc b/modules/ROOT/pages/metadata-testing.adoc new file mode 100644 index 00000000..fd810974 --- /dev/null +++ b/modules/ROOT/pages/metadata-testing.adoc @@ -0,0 +1,244 @@ += Metadata Testing +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +== Prerequisites + +. The following section assumes that you are already familiar on how to define `MetadataType` for your module. + +See xref:metadata.adoc[Adding DataSense Support] for more information. +. To create metadata tests you need to add the `mtf-tools` dependency to your project: ++ +[source,xml,linenums] +---- + + com.mulesoft.munit + mtf-tools + 1.0.0 + mule-plugin + test + +---- + +CAUTION: Metadata Testing is available since Mule Runtime version 4.2.0. When running your tests against a prior version, +suites containing metadata tests will be ignored. + + +== Tooling Test + +The `tooling-test` component is meant to validate the component's metadata at design time, unlike the `munit:test` that validates the component's execution. + +It has the following representation: + +[source,xml,linenums] +---- + + ... + +---- + +When a suite with tooling tests runs, XML validations are disabled. While testing metadata, it may be necessary to avoid filling required parameters. + +The tooling test can have the following parameters: + +[%header%autowidth.spread,cols="a,a"] +|=== +|Name |Description + +|`name` +| Mandatory. Defines the name of the test. The name must be unique inside the test suite. + +|`description` +|Describes the scenario being tested. + +|`ignore` +|Defines if the test should be ignored. If not present, the test is not ignored. + +|`tags` +|Comma separated list of tags to assign to the test. + +|`expectFailureCode` +|Defines the failure code that should be received after the metadata calculation of this test. + +|`expectFailureMessage` +|Defines the failure message that should be received after the metadata calculation of this test. + +|=== + +The tooling test has two main sections: + +* Metadata Scope: Wraps the component over which you need to calculate metadata, and defines the metadata information to obtain. + +Possible values are: +** Metadata Keys. +** Input Metadata. +** Output Metadata. +** Attributes Metadata. +* Validation: Has all the validations regarding the result of the metadata scope. + +== Metadata Scopes + +The following are scopes used inside the tooling test. Only one of them can be used in each test. + +You can use either an `operation` or a `source` in each of these scopes. + +=== Metadata Keys + +The `metadata keys` scope obtains the metadata keys for the component. The `payload` contains a map, where each key is the metadata key ID, and the value is the metadata key: + +[source,xml,linenums] +---- + + + + + + + + +---- + +=== Input Metadata + +The `input metadata` scope obtains the metadata type for the specified `parameter` of the component. The `payload` contains a JSON representation of the metadata type: + +[source,xml,linenums] +---- + + + + + + + + +---- + +=== Output Metadata + +The `output metadat` obtains the metadata type for the output `payload` of the component. The `payload` contains a JSON representation of the metadata type: + +[source,xml,linenums] +---- + + + + + + + + + + + + +---- + +=== Attributes Metadata + +The `attributes metadata` scope obtains the metadata type for the `attributes` metadata of the component. The `payload` contains a JSON representation of the metadata type: + +[source,xml,linenums] +---- + + + + + + + + + + +---- + +=== Get Values + +The `mtf:get-values` element retrieves the possible values for the specified `parameter` of the component. The `payload` contains a JSON representation of the values. + +[source,xml,linenums] +---- + + + + + + + + + + +---- + +== Expecting Failures + +A common use case when testing Metadata, is validating failures that may occur during metadata calculation. To validate these failures, you can use the `expectFailureCode` and `expectFailureMessage` parameters. + +[source,xml,linenums] +---- + + + + + +---- + +== Assert Type Processor + +The assert type processor allows you to assert the metadata type structure returned by metadata scopes such as `get-input-metadata`, `get-output-metadata` and `get-attributes-metadata`. + +The assert-type processor compares the structure of both metadata types, ignoring fields like `format` or `annotations`. To perform assertions over these fields, you can use the `payload` result of the metadata scopes operations as shown in the previous examples. + +If the assertion fails, the processor throws a `java.lang.AssertionError`. + +=== From Class + +To compare the metadata type structure against one obtained from a Java Class you use the `fromClass` parameter: + +[source,xml,linenums] +---- + + + + + + + + +---- + +The `actual` field defaults to `payload`. In the example above, you could choose not to specify it. For example: + +[source,xml,linenums] +-- + +-- + +=== From Schema + +To compare the metadata type structure against one obtained from a schema use the `fromSchema` parameter. + +The `fromSchema` supports metadata types from `JSON schema`, `XSD schema` and `RAML Data Types`. The file extensions need to be `.json`, `.xsd` and `.raml` respectively and stored in the `src/test/resources` folder. + +[source,xml,linenums] +---- + + + + + + + + +---- + + +The `actual` field defaults to `payload`. In the example above, you could choose not to specify it. For example: + +[source,xml,linenums] +-- + +-- + + +== See Also + diff --git a/modules/ROOT/pages/mtf-expecting-errors.adoc b/modules/ROOT/pages/mtf-expecting-errors.adoc new file mode 100644 index 00000000..bdebb0d7 --- /dev/null +++ b/modules/ROOT/pages/mtf-expecting-errors.adoc @@ -0,0 +1,78 @@ += Expecting Errors +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +Apart from validating the successful execution of your module's operations, you also must validate the errors that your module throws and the descriptions they generate. + +== Prerequesites + +* You are familiar with how to define the errors that your module throws. + +See xref:errors.adoc[Errors Definition] for more information. + +== Example + +Consider a module that defines errors as follows: + +.Error Type Definition +[source,java,linenums] +---- +public enum SimpleError implements ErrorTypeDefinition { + INVALID_PARAMETER, TIME_OUT, NOT_ALLOWED +} +---- + +.Error Type Provider +[source,java,linenums] +---- +public class ExecuteErrorsProvider implements ErrorTypeProvider { + @Override + public Set getErrorTypes() { + HashSet errors = new HashSet<>(); + errors.add(SimpleError.INVALID_PARAMETER); + errors.add(SimpleError.TIME_OUT); + return errors; + } +} +---- + +.Operation That Throws Error +[source,java,linenums] +---- +@Throws(ExecuteErrorsProvider.class) +public void execute(Integer number) { + if (number <= 0) { + throw new ModuleException("Parameter 'number' should be greater than 0", SimpleError.INVALID_PARAMETER); + } +} +---- + +You can create tests to validate the expected error type and error description. + +== Validating an Expected Error Type + +You can validate that the error thrown by the module in the example has the proper error type as follows: + +.Expect Error Type +[source, xml, linenums] +---- + + + + + +---- + +== Validating an Expected Error Description + +You can validate that the error thrown by the module in the example has the proper error description as follows: + +.Expect error description +[source, xml, linenums] +---- + + + + + +---- \ No newline at end of file diff --git a/modules/ROOT/pages/mtf-metadata-testing.adoc b/modules/ROOT/pages/mtf-metadata-testing.adoc new file mode 100644 index 00000000..056033a6 --- /dev/null +++ b/modules/ROOT/pages/mtf-metadata-testing.adoc @@ -0,0 +1,138 @@ += Metadata Testing Examples +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +The following examples provide a basic structure for testing the metadata defined for your module. + +== Prerequesites + +* You are familiar with how to define metadata in your module. + +See xref:metadata.adoc[Adding DataSense Support] and xref:metadata-testing.adoc[Metadata Testing] for more information. + +== Example + +Implementations provided in the following example use fixed values to simplify the code. You must obtain metadata through external services. + +Your module can define the following metadata: + +.Operation with Metadata +[source, java, linenums] +---- +@OutputResolver(output = ExampleOutputResolver.class) +public Object withMetadata(@MetadataKeyId(ExampleKeysResolver.class) String param) { + return null; +} +---- + +.TypeKeysResolver +[source, java, linenums] +---- +public class ExampleKeysResolver implements TypeKeysResolver { + + @Override + public Set getKeys(MetadataContext metadataContext) { + Set metadataKeys = new HashSet<>(); + metadataKeys.add(newKey("firstKey").withDisplayName("First Key").build()); + metadataKeys.add(newKey("secondKey").withDisplayName("Second Key").build()); + return metadataKeys; + } + + @Override + public String getCategoryName() { + return "ExampleCategory"; + } + +} +---- + +.OutputResolver +[source, java, linenums] +---- +public class ExampleOutputResolver implements OutputTypeResolver { + + @Override + public String getResolverName() { + return "exampleResolver"; + } + + @Override + public MetadataType getOutputType(MetadataContext context, String param) throws MetadataResolvingException { + if (param == null || param.isEmpty()) { + throw new MetadataResolvingException("No metadata available for an empty param", FailureCode.INVALID_METADATA_KEY); + } + ObjectTypeBuilder objectType = context.getTypeBuilder().objectType(); + objectType.addField().key("name").value().stringType(); + objectType.addField().key("age").value().numberType(); + return objectType.build(); + } + + @Override + public String getCategoryName() { + return "ExampleCategory"; + } +} +---- + +== Validating Metadata Keys + +The following example validates that the keys have the proper `Display` names: + +.Tooling test to validate metadata keys +[source, xml, linenums] +---- + + + + + + + + + +---- + +== Validating a Metadata Type + +The following test validates the `Metadata Type` value returned by the operation: + +.Tooling Test to Validate the Output Metadata Type of an Operation +[source, xml, linenums] +---- + + + + + + + + + + + + +---- + +== Validating an Expected Failure + +In the previous example, the module throws a `MetadataResolvingException` error when the parameter is null or empty. + +The following test validates that the proper failure code and message are thrown when the parameter is invalid: + +.Tooling test to validate metadata failures +[source, xml, linenums] +---- + + + + + +---- + + + + + + diff --git a/modules/ROOT/pages/mtf-parameterized-tests.adoc b/modules/ROOT/pages/mtf-parameterized-tests.adoc new file mode 100644 index 00000000..b76f9968 --- /dev/null +++ b/modules/ROOT/pages/mtf-parameterized-tests.adoc @@ -0,0 +1,105 @@ += Parameterized Test +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +A parameterized suite allows you to run the same tests with different inputs. See xref:munit::munit-parameterized-suite.adoc[MUnit Parameterized Test Suite] for more information. + +== Configuration Parameterization Example + +The following example shows a test suite with two parameterizations, each of them pointing to a different configuration: + +.Operation with a config +[source, java, linenums] +---- +public Integer withConfig(@Config ExampleConfig config) { + return config.getValue(); +} +---- + +You can test different configurations as follows: + +.Test that runs against different configurations +[source, xml, linenums] +---- + + + + + + + + + + + + + + + + + + + + + + + + + + + + +---- + +== Input Data Parameterization Example + +Suppose that you want to execute one operation but with different inputs, each with different expected outputs: for example, testing an operation that replaces one string input with another. Your operation uses the following syntax: + +.Operation for Different Inputs +[source, java, linenums] +---- +public String replace(String input, String toReplace, String replacement) { + return input.replace(toReplace, replacement); +} +---- + +Your test for several different inputs to one operation looks like this: + +.Test Case with Different Inputs +[source, xml, linenums] +---- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +---- + + + + diff --git a/modules/ROOT/pages/mtf-testing-examples.adoc b/modules/ROOT/pages/mtf-testing-examples.adoc new file mode 100644 index 00000000..f8995313 --- /dev/null +++ b/modules/ROOT/pages/mtf-testing-examples.adoc @@ -0,0 +1,17 @@ += SDK Testing Examples +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +This section links to examples that demonstrate common MUnit for SDK development usages, patterns and best practices. + +[%header%autowidth.spread,cols="a,a"] +|=== +| Example | Description +| xref:mtf-testing-sources.adoc[Testing Sources] | Different kind of sources require different kind of testing approaches +| xref:mtf-expecting-errors.adoc[Error Expectation] | Validate that your module throws the proper errors +| xref:mtf-metadata-testing.adoc[Metadata Testing] | Examples on how to test your Module's metadata +| xref:mtf-parameterized-tests.adoc[Parameterized test] | Using parameterization to reuse your tests +| xref:mtf-using-test-classes.adoc[Using Test classes] | How to use auxiliary classes for your tests +| xref:testing-oauth-modules.adoc[Testing OAuth Enabled Connectors] | How to test connectors that use OAuth authentication +|=== \ No newline at end of file diff --git a/modules/ROOT/pages/mtf-testing-sources.adoc b/modules/ROOT/pages/mtf-testing-sources.adoc new file mode 100644 index 00000000..b7a1edd8 --- /dev/null +++ b/modules/ROOT/pages/mtf-testing-sources.adoc @@ -0,0 +1,120 @@ += Testing Sources +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +Apart from defining operations, you might want to define sources for your module. + +Because sources must be placed at the beginning of a flow, they can't appear directly in the test. To test a source, you must have a flow with the source you want to test, and then a test that triggers it. + +There are several types of sources, each with its own distinct testing strategy. + +== Sources That Emit a Response + +The most common kind of test is when the source generates a synchronous response. To test this, you must hit the +source to get that response, and then assert it. + +For example, in the case of an `http:listener` you can hit the source with an `http:request`: + +.Hit source that emits a response +[source, xml, linenums] +---- + + + + + + + + + + + + <...> + + + + + +---- + +== Polling Sources + +Because the polling source polls items periodically with a given scheduling strategy, the test must trigger the +polling source and wait for the next poll. Then, it can validate the response generated by the source. + +=== Trigger a Single Time + +For a `file:listener` operation, you can trigger the source by creating new files: + +.Trigger polling source once +[source, xml, linenums] +---- + + + + + + + + #[payload] + + + + + + + + + + <...> + + + + + + + +---- + +=== Trigger Multiple Times + +.Trigger Polling Source Multiple Times +[source, xml, linenums] +---- + + + + + + + + #[payload] + + + + + + + + + + <...> + + + + + + + + + + + + + +---- + +== See Also + +* xref:sources.adoc[Creating Message Sources with the Mule SDK] \ No newline at end of file diff --git a/modules/ROOT/pages/mtf-using-test-classes.adoc b/modules/ROOT/pages/mtf-using-test-classes.adoc new file mode 100644 index 00000000..41e61a14 --- /dev/null +++ b/modules/ROOT/pages/mtf-using-test-classes.adoc @@ -0,0 +1,78 @@ += Using Test Classes +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +When developing test cases, you might want to use Java classes located in `src/test/java`. You can use Java classes through Java Module or through DataWeave. + +For the following example, assume that your class is located in `src/test/java/com/example/MyUtilClass.java`: + +.MyUtilClass +[source, java, linenums] +---- +package com.example.test; + +public class Helper { + + public static long getCurrentMillis() { + return System.currentTimeMillis(); + } + +} +---- + +== Using DataWeave + +To invoke static methods using DataWeave you must add the `java!` prefix to the package name of the class: + +.Using a Class in DataWeave +[source, xml, linenums] +---- + + + + + + + + +---- + +== Using Java Module + +. Ensure that the Java module is in your project: ++ +.Java Module dependency +[source, xml, linenums] +---- + + org.mule.module + mule-java-module + ${javaModule.version} + mule-plugin + test + +---- +. Use any of the Java Module's operations. + +In this case, invoke a static method of a class: ++ +.Using a class with the Java Module +[source, xml, linenums] +---- + + + + + + + + +---- + +MUnit Extensions Maven Plugin automatically exports any test packages and test resources in your +project. If your module is already exporting a class located in `src/main/java`, then any test classes with the same package +located in `src/test/java` won't be exported because this would cause a conflict. To be able to export both classes, you must change the test classes to a different package. + + + + diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc new file mode 100644 index 00000000..8dc2bdf6 --- /dev/null +++ b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc @@ -0,0 +1,577 @@ += MUnit Extensions Maven Plugin Configuration +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +== Additional argument lines + +Since the tests are being run in a new JVM, additional argument lines can be specified +to the JVM. Each argument should be specified in separate `argLine`. + +.Argument lines +[source,xml,linenums] +---- + + + com.mulesoft.munit + munit-extensions-maven-plugin + + ... + + -XX:MaxPermSize=512m + -Xmx1024m + + ... + + + +---- + +== To Enable Runtime Discovery + +Runtime Discovery looks for all runtime versions published on nexus, to run +against your tests. + +To enable MUnit Runtime Discovery, add the following configuration to the MUnit Plugin: + +.MUnit Runtime Discovery +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + + + CE <1> + + + ... + + + +---- +<1> This enables the runtime discovery feature for all released CE runtimes + +From the command line, the property is `discoverRuntimes.product`. + +NOTE: Product can be CE, EE or ALL (both CE and EE) + +=== To Include Snapshots + +If you want to include snapshot versions of the runtime you can add the following +line to the runtime configuration: + +.MUnit Runtime Discovery - Include Snapshots +[source,xml,linenums] +---- + + + CE + true + + +---- + +From the command line, the property is `discoverRuntimes.includeSnapshots`. + +Default value is `false`. + +=== Discovering Only the Latest Patches + +If you want to discover only the latest patch versions of Mule runtime engine, add the following line to the runtime configuration: + +.MUnit Runtime Discovery - Include Latest Patches +[source,xml,linenums] +---- + + + CE + true + + +---- + +From the command line, the property is `discoverRuntimes.latestPatches`. + +Default value is `true`. + +=== Discovering Since a Minimum Version + +By default, the runtime discovery searches for all Mule runtime engine versions since the `minMuleVersion` of the module. You can change this minimum version adding the following to the runtime configuration: + +.MUnit Runtime Discovery - Minimum Version +[source,xml,linenums] +---- + + + CE + 4.1.2 + + +---- + +From the command line, the property is `discoverRuntimes.minMuleVersion`. + +Default value is the `minMuleVersion` of the module. + +=== To Run Against Additional Runtimes + +By default, the plugin runs against the minMuleVersion and the required product of the module. +If you want to specify additional runtimes to run against, you can add the following to the runtime +configuration: + +.MUnit Runtime Configuration - Additional Runtimes +[source,xml,linenums] +---- + + + MULE_EE:4.1.2 + MULE:4.1.1 + + +---- + +From the command line, the property is `additionalRuntimes`. + +=== To Skip Runtime Discovery + +If you wish to skip runtime discovery, you can add the following line to the runtime configuration: + +.MUnit Runtime Discovery - Include Snapshots +[source,xml,linenums] +---- + + + CE + true + + +---- + +From the command line, the property is `discoverRuntimes.skip`. + +Default value is `false`. + +== Dynamic Ports + +[IMPORTANT] +MUnit 2.2 and later introduce the `dynamic-port` global element, that allows you to define dynamic ports at the MUnit suite level. + +Using this element instead of the plugin configuration described below allows you to set the dynamic port both from Maven and Studio. + +See xref:2.2@munit::dynamic-ports.adoc[Dynamic Ports] in MUnit to learn how to configure this element. + +When testing a Mule application in a continuous integration (CI) environment, you might encounter the following scenario: + + +When testing a module in a continuous integration (CI) environment, you might encounter the following scenario: + +`Your test tries to open a specific port. The port is already in use. The test fails with a port binding exception.` + +The easy solution to this problem is to have your test use a free port. +The MUnit Maven Plugin comes with a built-in feature to do just that. + +`MUnit Dynamic Ports` instructs the MUnit Maven Plugin to look for unbound ports and reserve them before running the tests over the module. Each port selected is placed in a system property under the name indicated in the configuration. +The test can acquire the port number through the use of placeholders afterward. + +TIP: The Ports to be selected by the plugin are taken from the following range: `[40000,50000)` + +[CAUTION] +-- +Dynamic Ports feature is only available as part of the MUnit Maven Plugin. + +You can not expect this feature to work when running tests from inside Anypoint Studio. +-- + +=== Enabling Dynamic Ports + +To enable the feature, you need to add the following code to the `configuration` section of the MUnit Maven Plugin: + +.Dynamic Ports Configuration +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + + a.dynamic.port + + ... + + + +---- + +If you have the `${http.port}` placeholder in your test, the configuration looks something like: + +.Example +[source,xml,linenums] +---- + + http.port + +---- + +== Enable surefire reports + +MUnit has built-in support for Surefire. No additional configuration is needed for this but it can be disabled if not needed. + + +//_TODO: Where? Properties? pluginConfig? +.Disabling surefire reports +[source,xml,linenums] +---- +false +---- + +The reports can be found under `${project.build.directory}/surefire-reports`. + +By default, it is set to `true`. + +== To Run Specific Tests + +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + example-MunitTest-suite.xml + ... + + + +---- + +== To Run Tests With Specific Tags + +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + exampleMunitTag + ... + + + +---- + +You can specify more than one tag by separating them using a comma. + +== To Skip MUnit Tests + +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + True + ... + + + +---- + + +// CONFIGURATION + +== To Skip Tests After One Suite Fails + +MUnit allows you to skip the rest of the tests if one test suite fails. + +If not specified, this value is false by default. + +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + true + ... + + + +---- + +== To Specify the Runtime Version + +MUnit allows you to specify the runtime version in which your module being tested will run. + +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + 1.2.3 + ... + + + +---- + +WARNING: If this option is set, runtime discovery and additionalRuntimes won't take effect. + +== To Specify The Runtime Product + +MUnit allows you to specify the type of runtime in which your module being tested will run. + +The two possible values are MULE for community edition, and MULE_EE for Enterprise Edition. + +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + MULE + ... + + + +---- + +WARNING: If this option is set, runtime discovery and additionalRuntimes won't take effect. + +== To Specify The JVM + +MUnit allows you to specify the jvm (or the java executable) in which your module being tested will run. +The property should be populated with the path to the executable. + +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + /path/to/jdk/bin/java + ... + + + +---- + +From the command line, the property is `-Dmunit.jvm` + +== Environment Variables + +To set additional environment variables during the test run, you can specify +them with the respective key and value. + +.Additional Environment Variables +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + + exampleValue + val2 + + ... + + + +---- + +Environment variables can be used to replace placeholders such as `${MY_ENV}` +(using the example above). + +== Redirect Test Output to File + +When running several tests, the build output can get very complex to read. You may want +to redirect the output of each Test suite to a file. This way what remains in the build +output will be the test results and to check the standard output of each test suite you can find it +in its respective file. + +These files will be located in the `testOutputDirectory` folder following this naming convention: +`munit.${suiteName}-output.txt`, where the `suiteName` represents the name of the XML file relative to the +MUnit test folder. + +The test run output that doesn't belong to a particular suite won't be printed to keep the build output clean, but it can be enabled by running maven in _debug_ mode. + +.Redirect test output to file +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + true + ... + + + +---- + +By default, it is set to `false` + +== System Properties Variables + +You may wish to define specific system variables needed for your MUnit test to run successfully. The example below shows how you can send them. + +.Setting system property variables +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + + my.property.value + + ... + + + +---- + +[TIP] +==== +Depending on the execution context, the system properties values may vary. When referencing these properties, it is a good practice to override their value to enforce test reproducibility. + +You can do so using the ­`-D` argument when running MUnit with Maven. + +Variables passed with the `-D` argument take full priority over any other property. + +For example: + +`-Dmy.property.key=my.property.another.value` +==== + +== Test Output Directory + +You may want to choose the location where the test output files will be created. +The path specified can be absolute or written as a maven placeholder. + +.Test output directory with absolute path +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + /my/absolute/path + ... + + + +---- + +.Test output directory using maven placeholders +[source,xml,linenums] +---- +${project.build.directory}/my/output/folder +---- + +By default, the files will be created in `${project.build.directory}/munit-reports/output/`. + +== Shared Libraries + +When requiring external libraries as explained xref:external-libs[here], you need to specify +these libraries as `sharedLibraries` (apart from having the corresponding dependencies in the project). + +For example if you defined the following annotation in your module: + +.External Library +[source,java,linenums] +---- +@ExternalLib(name = "My External Library", +requiredClassName = "com.example.MyClass", +coordinates = "com.example:my-external-library:1.2.3") +---- + +You should configure the plugin in the following way: + +.Shared Libraries +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + + + com.example + my-external-library + + + ... + + + +---- + +== Importing External Suites and Resources + +If you want to reuse suite files across different modules and they are present in an external artifact, the plugin +allows you to include them in the run (as if they were present in the `src/test/munit` and `src/test/resources` folders). + +Make sure that the dependencies are in the plugin's classpath adding them as dependencies of the plugin. + +You should configure the plugin in the following way: + +.External suites and resources +[source,xml,linenums] +---- + + + com.mulesoft.munit.tools + munit-extensions-maven-plugin + + ... + + suite1.xml + suite2.xml + + + example.json + + ... + + + + com.example + my-dependency + 1.0.0 + + + + +---- + +If any of the suite files or resources are not present in the classpath, the plugin fails. + + +== See Also + +* xref:munit-extensions-maven-plugin.adoc[MUnit Extensions Maven Plugin] diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin.adoc new file mode 100644 index 00000000..018e614a --- /dev/null +++ b/modules/ROOT/pages/munit-extensions-maven-plugin.adoc @@ -0,0 +1,95 @@ += Operating the MUnit Extensions Maven Plugin +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +This section shows you how to run your tests using the plugin. + +== Running MUnit Tests for a Module Project + +[source,console] +---- +mvn clean verify +---- + +== Running a Specific MUnit Test Suite + +You can instruct MUnit Maven Plugin to only run tests that belong to a specific test suite by using the property `munit.test`. + +[source,console] +---- +mvn clean verify -Dmunit.test= +---- +.The property `munit.test` accepts regular expressions. The expression is applied to the name of the MUnit Test Suite file. The regular expression language is the Java implementation. This path is relative to `src/test/munit`. + +The following is a valid example: +[source,console] +---- +mvn clean verify -Dmunit.test=.*my-test.* +---- + +You can leverage this feature by adding naming conventions to your MUnit Test suites. + +== To Run Specific MUnit Tests + +In the same way that you instruct MUnit to run one test suite, you can also tell it to run a specific test inside that test suite. To do so, we again make use of the property `munit.test`, with one addition: + +[source,console] +---- +mvn clean verify -Dmunit.test=# +---- + +The addition is the special character `#`. To the right of it, you should type the test name. It also accepts regular expressions. The expression is applied to the attribute `name` of the MUnit Test. + +The following is a valid example: +[source,console] +---- +mvn clean verify -Dmunit.test=.*my-test.*#.*test-scenario-1.* +---- + +[TIP] +-- +The tests inside the MUnit Test Suite that don't match the regular expression is flagged as *ignored*. +-- + +== To Run Tests Using a Specific Tag + +You can choose to run only the tests that you grouped under one specific tag. + +[source,console] +---- +mvn clean verify -Dmunit.tags= +---- + +== To Skip All Tests + +When building your module, you may want to prevent a test from running. MUnit leverages the same mechanism as Maven, so if you wish to skip tests, you can make use of the parameter `skipTests`. + +.Skipping Tests example +[source,console] +---- +mvn clean verify -DskipTests +---- + +== To Debug Tests + +When testing your module, you may want to debug your code. MUnit leverages Java remote debugging, so if you wish to debug your tests you can make user of the parameter `munit.debug`. + +.Debugging Code example +[source,console] +---- +mvn clean verify -Dmunit.debug +---- + +[TIP] +-- +The default debugger will listen on port 5005. You can override the debugger JVM argument line by specifying it as the value of the property. + +_mvn clean verify -Dmunit.debug="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8002"_ +-- + + +== See Also + +* xref:2.2@munit::faq-how-to-read-munit-test-results.adoc[FAQ: How To Read MUnit Test Results] +* xref:munit-extensions-maven-plugin-configuration.adoc[MUnit Extensions Maven Plugin Configuration] diff --git a/modules/ROOT/pages/testing-oauth-modules.adoc b/modules/ROOT/pages/testing-oauth-modules.adoc new file mode 100644 index 00000000..7a36ee82 --- /dev/null +++ b/modules/ROOT/pages/testing-oauth-modules.adoc @@ -0,0 +1,77 @@ += Testing OAuth-Enabled Connectors +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +Mule runtime engine supports authorization through various OAuth grant types, including `Authorization Code`. This grant type allows an external system (for example, your Mule application) to operate on behalf of a user without requiring user authentication. + +However, because the `Authorization Code` grant type is designed to force human intervention in the authentication process that identifies users using OAuth (OAuth dance), building an automated test for an application using this grant type is challenging. + +To overcome this challenge, you can use the Storage Event processor to bypass the OAuth dance by manually providing a valid access token. Note the following requirements: + +* It is your responsibility to manually obtain the token. +* It is your responsibility to be aware that the token will eventually expire. + +How often the token expires depends on the service provider to which you are connecting. +* It is your responsibility to obtain a new token and update the test with it. + +== Example + +Consider the following configuration of Salesforce Connector using OAuth authentication: + +[source,xml,linenums] +---- + + + //<1> + + + + + + //<2> + + +---- + +<1> The application defines an object store named `tokenStore`. +<2> It uses the `tokenStore` object store to store the OAuth token. + +To use the token stored in `tokenStore` in an MUnit test, create a flow and insert your token in an MUnit Storage Event processor: + +[source,xml,linenums] +---- + + + #[{param1: 'foo', param2: 3}] + + +---- + +Note that the `ownerConfigName` element matches the name of the Salesforce configuration. The access token and other properties shown here are placeholders for the values that you obtain by manually performing the OAuth dance. Then you supply the token to the test via system properties, a properties file, or whatever mechanism you choose. + +After you supply the token values, your Munit test has the following structure: + +[source,xml,linenums] +---- + + + //<1> + + + //<2> + + + .... Your assertions here .... + + +---- + +<1> Inserting the token by invoking the `storeOAuthToken` flow is the very first step in the test. +<2> The `` operation references the same config name and `resourceOwnerId` that matches the token you inserted. diff --git a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc new file mode 100644 index 00000000..56e2a394 --- /dev/null +++ b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc @@ -0,0 +1,196 @@ += Writing Your First MUnit Test (Beta) +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +This section provides a step-by-step introduction to testing a module's operation using MUnit. It explains how to configure your module and how to create a simple MUnit test. + +== Prerequisites + +* This article assumes you are familiar with MUnit concepts. + +To learn more about MUnit, see the xref:2.2@munit::index.adoc[MUnit] documentation. +* MUnit test cases should be located in the `src/test/munit` folder of your module. +* This example is based on the module project generated with the Mule Extension Archetype following the xref:getting-started.adoc#generating-a-project-using-the-maven-archetype-directly[Creating Your First SDK Project] instructions. + +== Configuring your Module + +To configure your module to run your MUnit test cases, you need to configure your `pom.xml` file. + +. Add the following properties: ++ +[source,xml,linenums] +---- + + … + + + src/test/munit + ${basedir}/target/test-mule/munit + 1.0.0 + 2.2.3 + 3.0.2 + ... + + ... + +---- +. Add the Maven Resources Plugin: ++ +[source,xml,linenums] +---- + + … + + + ... + + maven-resources-plugin + ${mavenResourcesVersion} + + + copy-munit-resources + process-test-resources + + copy-resources + + + ${munit.output.directory} + + + ${munit.input.directory} + true + + + + + + + ... + + + ... + +---- +. Add the MUnit Extensions Maven Plugin: ++ +[source,xml,linenums] +---- + + … + + + ... + + com.mulesoft.munit + munit-extensions-maven-plugin + ${munit.extensions.maven.plugin.version} + + + + test + + integration-test + + + + + com.mulesoft.munit + munit-runner + ${munit.version} + mule-plugin + + + com.mulesoft.munit + munit-tools + ${munit.version} + mule-plugin + + + + ... + + + ... + +---- + +== Writing Your MUnit Test + +You test a module by executing its operations and making assertions about the result of these executions. + +The MUnit Test XML must be placed inside the `src/test/munit` folder of the module project. + +[source,xml,linenums] +---- + + + + + + + + + + + + + + + + + + + + + + + + + + + +---- + +== Running your test + +To run your test from the command line using Maven: + +[source,bash,linenums] +---- +mvn clean verify +---- + +This outputs the result of your test run: +---- +================================================================================ +=== Running suite: basic-operations-test.xml === +================================================================================ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++ Running test: sayHiTest + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++ Running test: retrieveInfoTest + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +================================================================================ += Tests run: 2 - Failed: 0 - Errors: 0 - Skipped: 0 - Time elapsed: 2.55 sec = +================================================================================ +---- + +== See Also + +* xref:munit-extensions-maven-plugin.adoc[Operating the MUnit Extensions Maven Plugin] +* xref:munit-extensions-maven-plugin-configuration.adoc[MUnit Extensions Maven Plugin Configuration] diff --git a/modules/ROOT/pages/testing2.adoc b/modules/ROOT/pages/testing2.adoc new file mode 100644 index 00000000..a475344f --- /dev/null +++ b/modules/ROOT/pages/testing2.adoc @@ -0,0 +1,24 @@ += Testing Your Module +ifndef::env-site,env-github[] +include::_attributes.adoc[] +endif::[] + +Testing ensures that a piece of code works correctly. To properly test your module, you need to ensure two types of unit testing: one that tests your module's internal business logic, and another one that tests the interaction between your module and the runtime to ensure compatibility with the Mule ecosystem. + +The Module Testing Framework (Beta) leverages MUnit to provide this Mule ecosystem. + +Test cases that test internal business logic run during the `test` phase of your module's lifecycle. MUnit tests goal is to test the interaction of your module with the Mule environment. These tests run during the `integration-test` phase of your module's lifecycle. + +Below are a series of articles that explain in detail how to test your module. These articles provide a step-by-step introduction on how to test a module and explain the basics of the Module Testing Framework (Beta) +and how to execute a simple operation from a Module: + +* xref:testing-writing-your-first-munit-test.adoc[Writing your first MUnit test] +* xref:mtf-testing-examples.adoc[SDK Testing Examples] +* xref:munit-extensions-maven-plugin.adoc[Operating the MUnit Extensions Maven Plugin] +* xref:munit-extensions-maven-plugin-configuration.adoc[MUnit Extensions Maven Plugin Configuration] +* xref:metadata-testing.adoc[Metadata Testing] +* xref:connectivity-testing.adoc[Connectivity Testing] + +== See Also + +* xref:2.2@munit::index.adoc[MUnit] \ No newline at end of file From c6ef92a839e31543cf63c27902f5394631eeb955 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 19 Oct 2023 10:59:19 -0700 Subject: [PATCH 02/53] fix --- modules/ROOT/nav.adoc | 30 +++++++++---------- .../ROOT/pages/{testing2.adoc => mtf.adoc} | 0 2 files changed, 15 insertions(+), 15 deletions(-) rename modules/ROOT/pages/{testing2.adoc => mtf.adoc} (100%) diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 073a6b7a..e6fc514f 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -75,8 +75,6 @@ *** xref:sample-data.adoc[Sample Data] *** xref:security-best-practices.adoc[Security] *** xref:threading-asynchronous-processing.adoc[Threading and Asynchronous Processing] - ** xref:testing.adoc[Testing your Module] - *** xref:testing-writing-your-first-test-case.adoc[Writing Your First Test Case] ** xref:about-connector-certification-program-guidelines.adoc[About MuleSoft Connector Certification Program Guidelines] *** xref:certification-guidelines-for-connectors.adoc[Technical Guidelines for Connector Certifications] ** xref:troubleshooting.adoc[Troubleshooting] @@ -84,16 +82,18 @@ ** xref:validators.adoc[Validators with Mule SDK] ** xref:dmt.adoc[DevKit to SDK Migration Tool] * xref:xml-sdk.adoc[XML SDK] -* xref:testing2.adoc[MTF] - ** xref:testing-writing-your-first-munit-test.adoc[Writing Your First MUnit Test] - ** xref:mtf-testing-examples.adoc[SDK Testing Examples] - *** xref:mtf-expecting-errors.adoc[Expecting Errors] - *** xref:mtf-metadata-testing.adoc[Metadata Testing Examples] - *** xref:mtf-parameterized-tests.adoc[Parameterized Test] - *** xref:mtf-testing-sources.adoc[Testing Sources] - *** xref:mtf-using-test-classes.adoc[Using Test Classes] - *** xref:testing-oauth-modules.adoc[Testing OAuth Enabled Connectors] - ** xref:munit-extensions-maven-plugin.adoc[Operating the MUnit Extensions Maven Plugin] - ** xref:munit-extensions-maven-plugin-configuration.adoc[MUnit Extensions Maven Plugin Configuration] - ** xref:metadata-testing.adoc[Metadata Testing] - ** xref:connectivity-testing.adoc[Connectivity Testing] +* xref:testing.adoc[Testing Your Module] + ** xref:mtf.adoc[Module Testing Framework (MTF)] + *** xref:testing-writing-your-first-munit-test.adoc[Writing Your First MUnit Test] + *** xref:mtf-testing-examples.adoc[SDK Testing Examples] + **** xref:mtf-expecting-errors.adoc[Expecting Errors] + **** xref:mtf-metadata-testing.adoc[Metadata Testing Examples] + **** xref:mtf-parameterized-tests.adoc[Parameterized Test] + **** xref:mtf-testing-sources.adoc[Testing Sources] + **** xref:mtf-using-test-classes.adoc[Using Test Classes] + **** xref:testing-oauth-modules.adoc[Testing OAuth Enabled Connectors] + *** xref:munit-extensions-maven-plugin.adoc[Operating the MUnit Extensions Maven Plugin] + *** xref:munit-extensions-maven-plugin-configuration.adoc[MUnit Extensions Maven Plugin Configuration] + *** xref:metadata-testing.adoc[Metadata Testing] + *** xref:connectivity-testing.adoc[Connectivity Testing] + ** xref:testing-writing-your-first-test-case.adoc[FlowRunner (Deprecated)] diff --git a/modules/ROOT/pages/testing2.adoc b/modules/ROOT/pages/mtf.adoc similarity index 100% rename from modules/ROOT/pages/testing2.adoc rename to modules/ROOT/pages/mtf.adoc From fb12bc6f1bdc92a185f365b3779549f98bf51bfe Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 19 Oct 2023 13:24:10 -0700 Subject: [PATCH 03/53] more --- modules/ROOT/pages/mtf.adoc | 10 ++++++---- modules/ROOT/pages/testing.adoc | 9 +++++++-- 2 files changed, 13 insertions(+), 6 deletions(-) diff --git a/modules/ROOT/pages/mtf.adoc b/modules/ROOT/pages/mtf.adoc index a475344f..5aace784 100644 --- a/modules/ROOT/pages/mtf.adoc +++ b/modules/ROOT/pages/mtf.adoc @@ -1,13 +1,15 @@ -= Testing Your Module += Module Testing Framework (MTF) ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -Testing ensures that a piece of code works correctly. To properly test your module, you need to ensure two types of unit testing: one that tests your module's internal business logic, and another one that tests the interaction between your module and the runtime to ensure compatibility with the Mule ecosystem. +Module Testing Framework (MTF) tests your module built with Mule SDK for Java or XML to ensure the interaction between your module and Mule runtime is compatible with the Mule ecosystem. These tests run during the `integration-test` phase of your module's lifecycle. + +MTF is a plugin that extends xref:2.2@munit::index.adoc[MUnit]. While MUnit tests applications, MTF leverages MUnit to test modules. MTF enables you to run + + MTF is helpful because it allows you to run mule apps in a "lightweight" form and it not only provides a way to test connector's operations but also design operations -The Module Testing Framework (Beta) leverages MUnit to provide this Mule ecosystem. -Test cases that test internal business logic run during the `test` phase of your module's lifecycle. MUnit tests goal is to test the interaction of your module with the Mule environment. These tests run during the `integration-test` phase of your module's lifecycle. Below are a series of articles that explain in detail how to test your module. These articles provide a step-by-step introduction on how to test a module and explain the basics of the Module Testing Framework (Beta) and how to execute a simple operation from a Module: diff --git a/modules/ROOT/pages/testing.adoc b/modules/ROOT/pages/testing.adoc index f33c58d4..a8ed656d 100644 --- a/modules/ROOT/pages/testing.adoc +++ b/modules/ROOT/pages/testing.adoc @@ -3,8 +3,13 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -Testing ensures that a piece of code works correctly. Testing a module is more than simply creating test cases for the business logic. A lot of testing of the interaction -between the Module and Mule is required to ensure compatibility with the Mule ecosystem. +Test your module built with Mule SDK for Java or XML to ensure the interaction between your module and Mule runtime is compatible with the Mule ecosystem. + +You can test your module with Module Testing Framework (MTF). FlowRunner is deprecated. + +* <> +* <> + Here are a series of articles that explain in detail how to test your module. It provides a step-by-step introduction on how to test a module. It explains the basis of a Module Test Case and how to execute a simple operation from a Module. From ebbc499776c9d1ac1550f4e8d5f10fd02524b27d Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 19 Oct 2023 13:24:31 -0700 Subject: [PATCH 04/53] Update mtf.adoc --- modules/ROOT/pages/mtf.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/mtf.adoc b/modules/ROOT/pages/mtf.adoc index 5aace784..87f369bd 100644 --- a/modules/ROOT/pages/mtf.adoc +++ b/modules/ROOT/pages/mtf.adoc @@ -5,7 +5,7 @@ endif::[] Module Testing Framework (MTF) tests your module built with Mule SDK for Java or XML to ensure the interaction between your module and Mule runtime is compatible with the Mule ecosystem. These tests run during the `integration-test` phase of your module's lifecycle. -MTF is a plugin that extends xref:2.2@munit::index.adoc[MUnit]. While MUnit tests applications, MTF leverages MUnit to test modules. MTF enables you to run +MTF is a plugin that extends xref:2.3@munit::index.adoc[MUnit]. While MUnit tests applications, MTF leverages MUnit to test modules. MTF enables you to run MTF is helpful because it allows you to run mule apps in a "lightweight" form and it not only provides a way to test connector's operations but also design operations From ad05148057b462d7802d24a68ada1b7dcfba2634 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 19 Oct 2023 13:24:47 -0700 Subject: [PATCH 05/53] Update mtf.adoc --- modules/ROOT/pages/mtf.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/mtf.adoc b/modules/ROOT/pages/mtf.adoc index 87f369bd..313f45ca 100644 --- a/modules/ROOT/pages/mtf.adoc +++ b/modules/ROOT/pages/mtf.adoc @@ -5,7 +5,7 @@ endif::[] Module Testing Framework (MTF) tests your module built with Mule SDK for Java or XML to ensure the interaction between your module and Mule runtime is compatible with the Mule ecosystem. These tests run during the `integration-test` phase of your module's lifecycle. -MTF is a plugin that extends xref:2.3@munit::index.adoc[MUnit]. While MUnit tests applications, MTF leverages MUnit to test modules. MTF enables you to run +MTF is a plugin that extends xref:munit::index.adoc[MUnit]. While MUnit tests applications, MTF leverages MUnit to test modules. MTF enables you to run MTF is helpful because it allows you to run mule apps in a "lightweight" form and it not only provides a way to test connector's operations but also design operations From dabfc1f60a406d59af0be50c66f1a5de534dddf8 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 19 Oct 2023 13:58:39 -0700 Subject: [PATCH 06/53] Update mtf.adoc --- modules/ROOT/pages/mtf.adoc | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/modules/ROOT/pages/mtf.adoc b/modules/ROOT/pages/mtf.adoc index 313f45ca..43ed7749 100644 --- a/modules/ROOT/pages/mtf.adoc +++ b/modules/ROOT/pages/mtf.adoc @@ -3,13 +3,27 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -Module Testing Framework (MTF) tests your module built with Mule SDK for Java or XML to ensure the interaction between your module and Mule runtime is compatible with the Mule ecosystem. These tests run during the `integration-test` phase of your module's lifecycle. +Module Testing Framework (MTF) enables you to build tests for modules built with Mule SDK for Java or XML to ensure the interaction between modules and Mule runtime is compatible with the Mule ecosystem. MTF supports functional tests for your modules. These tests are run during the `integration-test` phase of your module's lifecycle. + +MTF is a plugin that extends xref:munit::index.adoc[MUnit]. While MUnit tests applications, MTF leverages MUnit to specifically test modules. If you build custom modules, you must use MTF to + -MTF is a plugin that extends xref:munit::index.adoc[MUnit]. While MUnit tests applications, MTF leverages MUnit to test modules. MTF enables you to run MTF is helpful because it allows you to run mule apps in a "lightweight" form and it not only provides a way to test connector's operations but also design operations +custom module, java 17 + +mtf performs functional tests, such as operations (non desgn and design), sources, + + + +Before You Begin +- munit + + +Next Steps +See Also Below are a series of articles that explain in detail how to test your module. These articles provide a step-by-step introduction on how to test a module and explain the basics of the Module Testing Framework (Beta) and how to execute a simple operation from a Module: From ce86bcec6ccaadeb74eab3d3346054ad03d913ca Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 19 Oct 2023 15:44:50 -0700 Subject: [PATCH 07/53] more --- modules/ROOT/pages/mtf.adoc | 38 ++++++++------------------------- modules/ROOT/pages/testing.adoc | 8 ++----- 2 files changed, 11 insertions(+), 35 deletions(-) diff --git a/modules/ROOT/pages/mtf.adoc b/modules/ROOT/pages/mtf.adoc index 43ed7749..c00f49da 100644 --- a/modules/ROOT/pages/mtf.adoc +++ b/modules/ROOT/pages/mtf.adoc @@ -3,38 +3,18 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -Module Testing Framework (MTF) enables you to build tests for modules built with Mule SDK for Java or XML to ensure the interaction between modules and Mule runtime is compatible with the Mule ecosystem. MTF supports functional tests for your modules. These tests are run during the `integration-test` phase of your module's lifecycle. +Module Testing Framework (MTF) enables you to create tests for modules built with Mule SDK for Java or XML to ensure the interaction between modules and Mule runtime is compatible with the Mule ecosystem. MTF supports functional tests for your modules. These tests are run during the `integration-test` phase of your module's lifecycle. -MTF is a plugin that extends xref:munit::index.adoc[MUnit]. While MUnit tests applications, MTF leverages MUnit to specifically test modules. If you build custom modules, you must use MTF to +MTF is a plugin that extends MUnit. While MUnit tests applications, MTF leverages MUnit to specifically test modules. If you build custom modules, you must use MTF to create tests to ensure module functionality and compatibility. +== Before You Begin +Before you begin using MTF, you must have: - MTF is helpful because it allows you to run mule apps in a "lightweight" form and it not only provides a way to test connector's operations but also design operations +* Familiarity with MUnit +* Anypoint Studio -custom module, java 17 +== See Also -mtf performs functional tests, such as operations (non desgn and design), sources, - - - -Before You Begin -- munit - - -Next Steps - -See Also - -Below are a series of articles that explain in detail how to test your module. These articles provide a step-by-step introduction on how to test a module and explain the basics of the Module Testing Framework (Beta) -and how to execute a simple operation from a Module: - -* xref:testing-writing-your-first-munit-test.adoc[Writing your first MUnit test] -* xref:mtf-testing-examples.adoc[SDK Testing Examples] -* xref:munit-extensions-maven-plugin.adoc[Operating the MUnit Extensions Maven Plugin] -* xref:munit-extensions-maven-plugin-configuration.adoc[MUnit Extensions Maven Plugin Configuration] -* xref:metadata-testing.adoc[Metadata Testing] -* xref:connectivity-testing.adoc[Connectivity Testing] - -== See Also - -* xref:2.2@munit::index.adoc[MUnit] \ No newline at end of file +* xref:munit::index.adoc[MUnit] +* xref:1.1@mule-sdk::index.adoc[Mule SDK] diff --git a/modules/ROOT/pages/testing.adoc b/modules/ROOT/pages/testing.adoc index a8ed656d..c4556b81 100644 --- a/modules/ROOT/pages/testing.adoc +++ b/modules/ROOT/pages/testing.adoc @@ -7,10 +7,6 @@ Test your module built with Mule SDK for Java or XML to ensure the interaction b You can test your module with Module Testing Framework (MTF). FlowRunner is deprecated. -* <> -* <> +* xref:mtf.adoc[Module Testing Framework (MTF)] +* xref:testing-writing-your-first-test-case[FlowRunner (Deprecated)] - -Here are a series of articles that explain in detail how to test your module. It provides a step-by-step introduction on how to test a module. It explains the basis of a Module Test Case and how to execute a simple operation from a Module. - -* <> (with xref:testing-writing-your-first-test-case.adoc#testing-flowrunner[FlowRunner]) From 299b056fa53ca1d3b122992651cd829c3eb43bd5 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 19 Oct 2023 16:05:46 -0700 Subject: [PATCH 08/53] more --- modules/ROOT/nav.adoc | 2 +- ...testing-writing-your-first-munit-test.adoc | 26 +++++++++++-------- 2 files changed, 16 insertions(+), 12 deletions(-) diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index e6fc514f..736d3741 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -84,7 +84,7 @@ * xref:xml-sdk.adoc[XML SDK] * xref:testing.adoc[Testing Your Module] ** xref:mtf.adoc[Module Testing Framework (MTF)] - *** xref:testing-writing-your-first-munit-test.adoc[Writing Your First MUnit Test] + *** xref:testing-writing-your-first-munit-test.adoc[Writing Your Test] *** xref:mtf-testing-examples.adoc[SDK Testing Examples] **** xref:mtf-expecting-errors.adoc[Expecting Errors] **** xref:mtf-metadata-testing.adoc[Metadata Testing Examples] diff --git a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc index 56e2a394..52e5ce8d 100644 --- a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc +++ b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc @@ -1,18 +1,20 @@ -= Writing Your First MUnit Test (Beta) += Creating Your Test ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -This section provides a step-by-step introduction to testing a module's operation using MUnit. It explains how to configure your module and how to create a simple MUnit test. +To test your module, you must create MUnit tests because MTF is built on top of MUnit. -== Prerequisites +This section provides a step-by-step example for testing a module using MUnit. This example is based on the module project generated with the Mule Extensions Archetype in xref:getting-started.adoc#generating-a-project-using-the-maven-archetype-directly[Creating Your First SDK Project]. -* This article assumes you are familiar with MUnit concepts. + -To learn more about MUnit, see the xref:2.2@munit::index.adoc[MUnit] documentation. -* MUnit test cases should be located in the `src/test/munit` folder of your module. -* This example is based on the module project generated with the Mule Extension Archetype following the xref:getting-started.adoc#generating-a-project-using-the-maven-archetype-directly[Creating Your First SDK Project] instructions. +To test your module, you must: -== Configuring your Module +. <>. +. <>. +. <>. + +[[configure-your-module]] +== Configure Your Module To configure your module to run your MUnit test cases, you need to configure your `pom.xml` file. @@ -120,8 +122,9 @@ To configure your module to run your MUnit test cases, you need to configure you ---- -== Writing Your MUnit Test - +[[write-your-test]] +== Write Your Test +//mention munit You test a module by executing its operations and making assertions about the result of these executions. The MUnit Test XML must be placed inside the `src/test/munit` folder of the module project. @@ -165,7 +168,8 @@ The MUnit Test XML must be placed inside the `src/test/munit` folder of the modu ---- -== Running your test +[[run-your-test]] +== Run Your Test To run your test from the command line using Maven: From 79070380ecfabf62368b2e10f9adaa93a57c97ba Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 19 Oct 2023 16:35:16 -0700 Subject: [PATCH 09/53] more --- .../testing-writing-your-first-munit-test.adoc | 16 ++++++++-------- .../testing-writing-your-first-test-case.adoc | 4 ++-- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc index 52e5ce8d..7fbe4f1b 100644 --- a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc +++ b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc @@ -10,13 +10,13 @@ This section provides a step-by-step example for testing a module using MUnit. T To test your module, you must: . <>. -. <>. -. <>. +. <>. +. <>. [[configure-your-module]] == Configure Your Module -To configure your module to run your MUnit test cases, you need to configure your `pom.xml` file. +To configure your module to run your MUnit tests, you must configure your `pom.xml` file: . Add the following properties: + @@ -123,8 +123,8 @@ To configure your module to run your MUnit test cases, you need to configure you ---- [[write-your-test]] -== Write Your Test -//mention munit +== Write Your MUnit Test + You test a module by executing its operations and making assertions about the result of these executions. The MUnit Test XML must be placed inside the `src/test/munit` folder of the module project. @@ -149,10 +149,10 @@ The MUnit Test XML must be placed inside the `src/test/munit` folder of the modu - + - + @@ -169,7 +169,7 @@ The MUnit Test XML must be placed inside the `src/test/munit` folder of the modu ---- [[run-your-test]] -== Run Your Test +== Run Your MUnit Test To run your test from the command line using Maven: diff --git a/modules/ROOT/pages/testing-writing-your-first-test-case.adoc b/modules/ROOT/pages/testing-writing-your-first-test-case.adoc index 07973cd0..8eeeda74 100644 --- a/modules/ROOT/pages/testing-writing-your-first-test-case.adoc +++ b/modules/ROOT/pages/testing-writing-your-first-test-case.adoc @@ -120,7 +120,7 @@ of the flow execution. This variable is required for obtaining the value of the Object payloadValue = event.getMessage() .getPayload() .getValue(); - assertThat(payloadValue, is("Hello Mariano Gonzales!!!")) + assertThat(payloadValue, is("Hello!")) ---- === 4.3 Summary @@ -136,7 +136,7 @@ public void executeSayHiOperation() throws Exception { .getMessage() .getPayload() .getValue()); //<2> - assertThat(payloadValue, is("Hello Mariano Gonzales!!!")); //<3> + assertThat(payloadValue, is("Hello!")); //<3> } ---- <1> Executes the `sayHiFlow` flow. From ededa5037ca3ec3ac1ab012fa49272d05fb9e362 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 19 Oct 2023 16:35:28 -0700 Subject: [PATCH 10/53] Update testing-writing-your-first-test-case.adoc --- modules/ROOT/pages/testing-writing-your-first-test-case.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/testing-writing-your-first-test-case.adoc b/modules/ROOT/pages/testing-writing-your-first-test-case.adoc index 8eeeda74..a01a51f3 100644 --- a/modules/ROOT/pages/testing-writing-your-first-test-case.adoc +++ b/modules/ROOT/pages/testing-writing-your-first-test-case.adoc @@ -47,7 +47,7 @@ The Mule app XML must be placed inside the `src/test/resources` folder of the mo - + From 5e2e5ebeddf7f52fe6a9505eb891571eb73b3684 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 19 Oct 2023 16:39:43 -0700 Subject: [PATCH 11/53] Update testing-writing-your-first-munit-test.adoc --- .../ROOT/pages/testing-writing-your-first-munit-test.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc index 7fbe4f1b..62775520 100644 --- a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc +++ b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc @@ -125,9 +125,9 @@ To configure your module to run your MUnit tests, you must configure your `pom.x [[write-your-test]] == Write Your MUnit Test -You test a module by executing its operations and making assertions about the result of these executions. +To test your module, your MUnit test must execute of the module's operations and make assertions about the result of these executions. -The MUnit Test XML must be placed inside the `src/test/munit` folder of the module project. +The MUnit test XML must be placed inside the `src/test/munit` folder of the module project. [source,xml,linenums] ---- @@ -171,7 +171,7 @@ The MUnit Test XML must be placed inside the `src/test/munit` folder of the modu [[run-your-test]] == Run Your MUnit Test -To run your test from the command line using Maven: +Run your test from the command line using Maven: [source,bash,linenums] ---- From b8fee755aeb322f43d6a6f5e1952d248fce69142 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 19 Oct 2023 16:40:19 -0700 Subject: [PATCH 12/53] Update nav.adoc --- modules/ROOT/nav.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 736d3741..270682fb 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -84,7 +84,7 @@ * xref:xml-sdk.adoc[XML SDK] * xref:testing.adoc[Testing Your Module] ** xref:mtf.adoc[Module Testing Framework (MTF)] - *** xref:testing-writing-your-first-munit-test.adoc[Writing Your Test] + *** xref:testing-writing-your-first-munit-test.adoc[Creating Your Test] *** xref:mtf-testing-examples.adoc[SDK Testing Examples] **** xref:mtf-expecting-errors.adoc[Expecting Errors] **** xref:mtf-metadata-testing.adoc[Metadata Testing Examples] From a88ef09e53aa5dda33b07d96f1f5af9d59f88e70 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Fri, 20 Oct 2023 13:29:32 -0700 Subject: [PATCH 13/53] more --- modules/ROOT/pages/mtf.adoc | 2 +- .../ROOT/pages/testing-writing-your-first-munit-test.adoc | 7 ++++--- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/modules/ROOT/pages/mtf.adoc b/modules/ROOT/pages/mtf.adoc index c00f49da..bc34a18c 100644 --- a/modules/ROOT/pages/mtf.adoc +++ b/modules/ROOT/pages/mtf.adoc @@ -17,4 +17,4 @@ Before you begin using MTF, you must have: == See Also * xref:munit::index.adoc[MUnit] -* xref:1.1@mule-sdk::index.adoc[Mule SDK] +* xref:studio::index.adoc[Anypoint Studio] diff --git a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc index 62775520..df9a280c 100644 --- a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc +++ b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc @@ -125,7 +125,7 @@ To configure your module to run your MUnit tests, you must configure your `pom.x [[write-your-test]] == Write Your MUnit Test -To test your module, your MUnit test must execute of the module's operations and make assertions about the result of these executions. +To test your module, your MUnit test must execute the module's operations and make assertions about the result of these executions. The MUnit test XML must be placed inside the `src/test/munit` folder of the module project. @@ -196,5 +196,6 @@ This outputs the result of your test run: == See Also -* xref:munit-extensions-maven-plugin.adoc[Operating the MUnit Extensions Maven Plugin] -* xref:munit-extensions-maven-plugin-configuration.adoc[MUnit Extensions Maven Plugin Configuration] +* xref:munit-extensions-maven-plugin-configuration.adoc[Configuring the MUnit Extensions Maven Plugin] +* xref:munit-extensions-maven-plugin.adoc[Running the MUnit Extensions Maven Plugin] + From 6ebeaa0b5bb107f04fe1934240fcb9b695fe99e7 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Fri, 20 Oct 2023 13:57:25 -0700 Subject: [PATCH 14/53] more --- modules/ROOT/nav.adoc | 2 +- modules/ROOT/pages/mtf-testing-examples.adoc | 16 ++++++++-------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 270682fb..f78d730a 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -85,7 +85,7 @@ * xref:testing.adoc[Testing Your Module] ** xref:mtf.adoc[Module Testing Framework (MTF)] *** xref:testing-writing-your-first-munit-test.adoc[Creating Your Test] - *** xref:mtf-testing-examples.adoc[SDK Testing Examples] + *** xref:mtf-testing-examples.adoc[MTF Test Examples] **** xref:mtf-expecting-errors.adoc[Expecting Errors] **** xref:mtf-metadata-testing.adoc[Metadata Testing Examples] **** xref:mtf-parameterized-tests.adoc[Parameterized Test] diff --git a/modules/ROOT/pages/mtf-testing-examples.adoc b/modules/ROOT/pages/mtf-testing-examples.adoc index f8995313..8f75c952 100644 --- a/modules/ROOT/pages/mtf-testing-examples.adoc +++ b/modules/ROOT/pages/mtf-testing-examples.adoc @@ -1,17 +1,17 @@ -= SDK Testing Examples += MTF Test Examples ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -This section links to examples that demonstrate common MUnit for SDK development usages, patterns and best practices. +This section links to examples of tests that demonstrate common uses, patterns, and best practices for your modules. [%header%autowidth.spread,cols="a,a"] |=== | Example | Description -| xref:mtf-testing-sources.adoc[Testing Sources] | Different kind of sources require different kind of testing approaches -| xref:mtf-expecting-errors.adoc[Error Expectation] | Validate that your module throws the proper errors -| xref:mtf-metadata-testing.adoc[Metadata Testing] | Examples on how to test your Module's metadata -| xref:mtf-parameterized-tests.adoc[Parameterized test] | Using parameterization to reuse your tests -| xref:mtf-using-test-classes.adoc[Using Test classes] | How to use auxiliary classes for your tests -| xref:testing-oauth-modules.adoc[Testing OAuth Enabled Connectors] | How to test connectors that use OAuth authentication +| xref:mtf-testing-sources.adoc[Sources Tests] | Different kind of sources require different kind of testing approaches +| xref:mtf-expecting-errors.adoc[Expected Errors Tests] | Validate that your module throws the proper errors. +| xref:mtf-metadata-testing.adoc[Metadata Tests] | Test your module's metadata. +| xref:mtf-parameterized-tests.adoc[Parameterized Tests] | Use parameterization to reuse your tests. +| xref:mtf-using-test-classes.adoc[Class Tests] | Use auxiliary classes for your tests. +| xref:testing-oauth-modules.adoc[OAuth Enabled Modules Tests] | Test modules that use OAuth authentication. |=== \ No newline at end of file From 6bc9f28bb7bbc80e1c4ad0e3edc7b8fb743f1c1b Mon Sep 17 00:00:00 2001 From: sathya0 Date: Mon, 23 Oct 2023 12:48:07 -0700 Subject: [PATCH 15/53] fixes --- modules/ROOT/nav.adoc | 14 +++++++------- modules/ROOT/pages/mtf-testing-examples.adoc | 12 ++++++------ .../testing-writing-your-first-test-case.adoc | 2 ++ 3 files changed, 15 insertions(+), 13 deletions(-) diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index f78d730a..0a16ba06 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -86,14 +86,14 @@ ** xref:mtf.adoc[Module Testing Framework (MTF)] *** xref:testing-writing-your-first-munit-test.adoc[Creating Your Test] *** xref:mtf-testing-examples.adoc[MTF Test Examples] - **** xref:mtf-expecting-errors.adoc[Expecting Errors] - **** xref:mtf-metadata-testing.adoc[Metadata Testing Examples] - **** xref:mtf-parameterized-tests.adoc[Parameterized Test] - **** xref:mtf-testing-sources.adoc[Testing Sources] - **** xref:mtf-using-test-classes.adoc[Using Test Classes] - **** xref:testing-oauth-modules.adoc[Testing OAuth Enabled Connectors] + **** xref:mtf-testing-sources.adoc[Sources] + **** xref:mtf-expecting-errors.adoc[Expected Errors] + **** xref:mtf-metadata-testing.adoc[Metadata] + **** xref:mtf-parameterized-tests.adoc[Parameterization] + **** xref:mtf-using-test-classes.adoc[Classes] + **** xref:testing-oauth-modules.adoc[OAuth Enabled Connectors] + *** xref:munit-extensions-maven-plugin-configuration.adoc[Configuring the MUnit Extensions Maven Plugin] *** xref:munit-extensions-maven-plugin.adoc[Operating the MUnit Extensions Maven Plugin] - *** xref:munit-extensions-maven-plugin-configuration.adoc[MUnit Extensions Maven Plugin Configuration] *** xref:metadata-testing.adoc[Metadata Testing] *** xref:connectivity-testing.adoc[Connectivity Testing] ** xref:testing-writing-your-first-test-case.adoc[FlowRunner (Deprecated)] diff --git a/modules/ROOT/pages/mtf-testing-examples.adoc b/modules/ROOT/pages/mtf-testing-examples.adoc index 8f75c952..b277e9b8 100644 --- a/modules/ROOT/pages/mtf-testing-examples.adoc +++ b/modules/ROOT/pages/mtf-testing-examples.adoc @@ -8,10 +8,10 @@ This section links to examples of tests that demonstrate common uses, patterns, [%header%autowidth.spread,cols="a,a"] |=== | Example | Description -| xref:mtf-testing-sources.adoc[Sources Tests] | Different kind of sources require different kind of testing approaches -| xref:mtf-expecting-errors.adoc[Expected Errors Tests] | Validate that your module throws the proper errors. -| xref:mtf-metadata-testing.adoc[Metadata Tests] | Test your module's metadata. -| xref:mtf-parameterized-tests.adoc[Parameterized Tests] | Use parameterization to reuse your tests. -| xref:mtf-using-test-classes.adoc[Class Tests] | Use auxiliary classes for your tests. -| xref:testing-oauth-modules.adoc[OAuth Enabled Modules Tests] | Test modules that use OAuth authentication. +| xref:mtf-testing-sources.adoc[Sources] | Learn how different types of sources require different types of testing approaches. +| xref:mtf-expecting-errors.adoc[Expected Errors] | Validate that your module throws the proper errors. +| xref:mtf-metadata-testing.adoc[Metadata] | Test your module's metadata. +| xref:mtf-parameterized-tests.adoc[Parameterization] | Use parameterization to reuse your tests. +| xref:mtf-using-test-classes.adoc[Classes] | Use auxiliary classes for your tests. +| xref:testing-oauth-modules.adoc[OAuth Enabled Modules] | Test modules that use OAuth authentication. |=== \ No newline at end of file diff --git a/modules/ROOT/pages/testing-writing-your-first-test-case.adoc b/modules/ROOT/pages/testing-writing-your-first-test-case.adoc index a01a51f3..c7a63af4 100644 --- a/modules/ROOT/pages/testing-writing-your-first-test-case.adoc +++ b/modules/ROOT/pages/testing-writing-your-first-test-case.adoc @@ -3,6 +3,8 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] +NOTE: This guide uses FlowRunner, which is deprecated. To test your modules, refer to the xref:mtf.adoc[MTF] documentation instead. + This section provides a step-by-step introduction to testing a module's operation. It explains the basics of test cases that you must perform. From 49480e2298e08e75f3c14627b839e1ae24e9eb93 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Mon, 23 Oct 2023 14:06:07 -0700 Subject: [PATCH 16/53] Update mtf-testing-sources.adoc --- modules/ROOT/pages/mtf-testing-sources.adoc | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/modules/ROOT/pages/mtf-testing-sources.adoc b/modules/ROOT/pages/mtf-testing-sources.adoc index b7a1edd8..c3c9b630 100644 --- a/modules/ROOT/pages/mtf-testing-sources.adoc +++ b/modules/ROOT/pages/mtf-testing-sources.adoc @@ -1,22 +1,18 @@ -= Testing Sources += Sources ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -Apart from defining operations, you might want to define sources for your module. - -Because sources must be placed at the beginning of a flow, they can't appear directly in the test. To test a source, you must have a flow with the source you want to test, and then a test that triggers it. +Because sources must be placed at the beginning of a flow, they cannot appear directly in the test. To test a source, you must have a flow with the source you want to test, and then a test that triggers the source. There are several types of sources, each with its own distinct testing strategy. == Sources That Emit a Response -The most common kind of test is when the source generates a synchronous response. To test this, you must hit the -source to get that response, and then assert it. +The most common kind of test is when the source generates a synchronous response. To test a source that emits a response, you must trigger the source to get that response, and then assert it. -For example, in the case of an `http:listener` you can hit the source with an `http:request`: +For example, in the case of an `http:listener`, you can trigger the source with an `http:request`: -.Hit source that emits a response [source, xml, linenums] ---- @@ -40,14 +36,12 @@ For example, in the case of an `http:listener` you can hit the source with an `h == Polling Sources -Because the polling source polls items periodically with a given scheduling strategy, the test must trigger the -polling source and wait for the next poll. Then, it can validate the response generated by the source. +Because a polling source polls items periodically with a given scheduling strategy, the test must trigger the polling source and wait for the next poll. Then, the test can validate the response generated by the polling source. === Trigger a Single Time -For a `file:listener` operation, you can trigger the source by creating new files: +You can trigger the polling source a single time. For example, for a `file:listener` operation, you can trigger the polling source by creating new files: -.Trigger polling source once [source, xml, linenums] ---- @@ -79,7 +73,8 @@ For a `file:listener` operation, you can trigger the source by creating new file === Trigger Multiple Times -.Trigger Polling Source Multiple Times +You can trigger the polling source multiple times: + [source, xml, linenums] ---- From c3ab565e07df25d17ee7ee32c1c204a5f08ff992 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Mon, 23 Oct 2023 15:55:49 -0700 Subject: [PATCH 17/53] Update mtf-expecting-errors.adoc --- modules/ROOT/pages/mtf-expecting-errors.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/modules/ROOT/pages/mtf-expecting-errors.adoc b/modules/ROOT/pages/mtf-expecting-errors.adoc index bdebb0d7..0eef5aec 100644 --- a/modules/ROOT/pages/mtf-expecting-errors.adoc +++ b/modules/ROOT/pages/mtf-expecting-errors.adoc @@ -1,11 +1,11 @@ -= Expecting Errors += Expected Errors ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -Apart from validating the successful execution of your module's operations, you also must validate the errors that your module throws and the descriptions they generate. +You must validate the error types and error descriptions that your module throws. -== Prerequesites +== Prerequisites * You are familiar with how to define the errors that your module throws. + See xref:errors.adoc[Errors Definition] for more information. From f6c40d54e8dea17cd1002445d38e96772e57d019 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Tue, 24 Oct 2023 13:10:35 -0700 Subject: [PATCH 18/53] editorial --- modules/ROOT/pages/mtf.adoc | 2 +- .../testing-writing-your-first-munit-test.adoc | 18 +++++++++--------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/modules/ROOT/pages/mtf.adoc b/modules/ROOT/pages/mtf.adoc index bc34a18c..8c858e08 100644 --- a/modules/ROOT/pages/mtf.adoc +++ b/modules/ROOT/pages/mtf.adoc @@ -3,7 +3,7 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -Module Testing Framework (MTF) enables you to create tests for modules built with Mule SDK for Java or XML to ensure the interaction between modules and Mule runtime is compatible with the Mule ecosystem. MTF supports functional tests for your modules. These tests are run during the `integration-test` phase of your module's lifecycle. +Use Module Testing Framework (MTF) to create tests for modules built with Mule SDK for Java or XML to ensure the interaction between modules and Mule runtime is compatible with the Mule ecosystem. MTF supports functional tests for your modules. You run these tests during the `integration-test` phase of your module's lifecycle. MTF is a plugin that extends MUnit. While MUnit tests applications, MTF leverages MUnit to specifically test modules. If you build custom modules, you must use MTF to create tests to ensure module functionality and compatibility. diff --git a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc index df9a280c..00d34a44 100644 --- a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc +++ b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc @@ -3,16 +3,14 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -To test your module, you must create MUnit tests because MTF is built on top of MUnit. - -This section provides a step-by-step example for testing a module using MUnit. This example is based on the module project generated with the Mule Extensions Archetype in xref:getting-started.adoc#generating-a-project-using-the-maven-archetype-directly[Creating Your First SDK Project]. - -To test your module, you must: +To test your module, you must create MUnit tests because MTF depends on MUnit. To test your module, you must: . <>. . <>. . <>. +The following example, based on the module project generated with the Mule Extensions Archetype in xref:getting-started.adoc#generating-a-project-using-the-maven-archetype-directly[Creating Your First SDK Project], shows a step-by-step process of testing a module using MUnit. + [[configure-your-module]] == Configure Your Module @@ -77,7 +75,7 @@ To configure your module to run your MUnit tests, you must configure your `pom.x ... ---- -. Add the MUnit Extensions Maven Plugin: +. Add the MUnit Extensions Maven plugin: + [source,xml,linenums] ---- @@ -127,7 +125,7 @@ To configure your module to run your MUnit tests, you must configure your `pom.x To test your module, your MUnit test must execute the module's operations and make assertions about the result of these executions. -The MUnit test XML must be placed inside the `src/test/munit` folder of the module project. +You must place the MUnit test XML inside the `src/test/munit` folder of the module project. [source,xml,linenums] ---- @@ -179,6 +177,8 @@ mvn clean verify ---- This outputs the result of your test run: + +[source,bash,linenums] ---- ================================================================================ === Running suite: basic-operations-test.xml === @@ -196,6 +196,6 @@ This outputs the result of your test run: == See Also -* xref:munit-extensions-maven-plugin-configuration.adoc[Configuring the MUnit Extensions Maven Plugin] -* xref:munit-extensions-maven-plugin.adoc[Running the MUnit Extensions Maven Plugin] +* xref:munit-extensions-maven-plugin-configuration.adoc[] +* xref:munit-extensions-maven-plugin.adoc[] From 24f26bf2dd8c2812ff28b413883cd06a93c56be4 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 26 Oct 2023 09:12:57 -0700 Subject: [PATCH 19/53] fixes --- modules/ROOT/pages/mtf-testing-examples.adoc | 2 +- modules/ROOT/pages/mtf-testing-sources.adoc | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/modules/ROOT/pages/mtf-testing-examples.adoc b/modules/ROOT/pages/mtf-testing-examples.adoc index b277e9b8..1ec55fe1 100644 --- a/modules/ROOT/pages/mtf-testing-examples.adoc +++ b/modules/ROOT/pages/mtf-testing-examples.adoc @@ -3,7 +3,7 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -This section links to examples of tests that demonstrate common uses, patterns, and best practices for your modules. +Here are some examples of tests that demonstrate common uses, patterns, and best practices for your modules. [%header%autowidth.spread,cols="a,a"] |=== diff --git a/modules/ROOT/pages/mtf-testing-sources.adoc b/modules/ROOT/pages/mtf-testing-sources.adoc index c3c9b630..86890f87 100644 --- a/modules/ROOT/pages/mtf-testing-sources.adoc +++ b/modules/ROOT/pages/mtf-testing-sources.adoc @@ -3,15 +3,15 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -Because sources must be placed at the beginning of a flow, they cannot appear directly in the test. To test a source, you must have a flow with the source you want to test, and then a test that triggers the source. +Because you must place sources at the beginning of a flow, they cannot appear directly in the test. To test a source, you must have a flow with the source you want to test, and then a test that triggers the source. There are several types of sources, each with its own distinct testing strategy. == Sources That Emit a Response -The most common kind of test is when the source generates a synchronous response. To test a source that emits a response, you must trigger the source to get that response, and then assert it. +The most common type of test is when the source generates a synchronous response. To test a source that emits a response, you must trigger the source to get that response, and then assert it. -For example, in the case of an `http:listener`, you can trigger the source with an `http:request`: +For example, in the case of `http:listener`, you can trigger the source with `http:request`: [source, xml, linenums] ---- @@ -38,7 +38,7 @@ For example, in the case of an `http:listener`, you can trigger the source with Because a polling source polls items periodically with a given scheduling strategy, the test must trigger the polling source and wait for the next poll. Then, the test can validate the response generated by the polling source. -=== Trigger a Single Time +=== Trigger a Polling Source a Single Time You can trigger the polling source a single time. For example, for a `file:listener` operation, you can trigger the polling source by creating new files: @@ -71,7 +71,7 @@ You can trigger the polling source a single time. For example, for a `file:liste ---- -=== Trigger Multiple Times +=== Trigger a Polling Source Multiple Times You can trigger the polling source multiple times: @@ -112,4 +112,4 @@ You can trigger the polling source multiple times: == See Also -* xref:sources.adoc[Creating Message Sources with the Mule SDK] \ No newline at end of file +* xref:sources.adoc[] \ No newline at end of file From 029ec3e13db1c280606a1b5e54d9207db9df7b4b Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 26 Oct 2023 10:41:56 -0700 Subject: [PATCH 20/53] Update mtf-expecting-errors.adoc --- modules/ROOT/pages/mtf-expecting-errors.adoc | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/modules/ROOT/pages/mtf-expecting-errors.adoc b/modules/ROOT/pages/mtf-expecting-errors.adoc index 0eef5aec..a664689a 100644 --- a/modules/ROOT/pages/mtf-expecting-errors.adoc +++ b/modules/ROOT/pages/mtf-expecting-errors.adoc @@ -7,14 +7,13 @@ You must validate the error types and error descriptions that your module throws == Prerequisites -* You are familiar with how to define the errors that your module throws. + -See xref:errors.adoc[Errors Definition] for more information. +* You must know how to define the errors that your module throws. For more information, refer to xref:errors.adoc[Errors Definition]. == Example -Consider a module that defines errors as follows: +Suppose there is a module that defines errors as follows: -.Error Type Definition +.Error type definition [source,java,linenums] ---- public enum SimpleError implements ErrorTypeDefinition { @@ -22,7 +21,7 @@ public enum SimpleError implements ErrorTypeDefinition { } ---- -.Error Type Provider +.Error type provider [source,java,linenums] ---- public class ExecuteErrorsProvider implements ErrorTypeProvider { @@ -36,7 +35,7 @@ public class ExecuteErrorsProvider implements ErrorTypeProvider { } ---- -.Operation That Throws Error +.Operation that throws the error [source,java,linenums] ---- @Throws(ExecuteErrorsProvider.class) @@ -53,7 +52,6 @@ You can create tests to validate the expected error type and error description. You can validate that the error thrown by the module in the example has the proper error type as follows: -.Expect Error Type [source, xml, linenums] ---- @@ -67,7 +65,6 @@ You can validate that the error thrown by the module in the example has the prop You can validate that the error thrown by the module in the example has the proper error description as follows: -.Expect error description [source, xml, linenums] ---- From 3f0d9aee78eb0257f8ef4e96152ed8d0da9ac710 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 26 Oct 2023 11:20:41 -0700 Subject: [PATCH 21/53] more --- modules/ROOT/pages/mtf-expecting-errors.adoc | 2 +- modules/ROOT/pages/mtf-metadata-testing.adoc | 238 ++++++++++++++++++- 2 files changed, 238 insertions(+), 2 deletions(-) diff --git a/modules/ROOT/pages/mtf-expecting-errors.adoc b/modules/ROOT/pages/mtf-expecting-errors.adoc index a664689a..2f358b37 100644 --- a/modules/ROOT/pages/mtf-expecting-errors.adoc +++ b/modules/ROOT/pages/mtf-expecting-errors.adoc @@ -3,7 +3,7 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -You must validate the error types and error descriptions that your module throws. +Validate the error types and error descriptions that your module throws. == Prerequisites diff --git a/modules/ROOT/pages/mtf-metadata-testing.adoc b/modules/ROOT/pages/mtf-metadata-testing.adoc index 056033a6..49137a90 100644 --- a/modules/ROOT/pages/mtf-metadata-testing.adoc +++ b/modules/ROOT/pages/mtf-metadata-testing.adoc @@ -1,8 +1,244 @@ -= Metadata Testing Examples += Metadata ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] +Test the metadata defined for your module. + +== Prerequisites + +* You must know how to define `MetadataType` for your module. For more information, refer to xref:metadata.adoc[Adding DataSense Support]. +* To create metadata tests, you must add the `mtf-tools` dependency to your project: ++ +[source,xml,linenums] +---- + + com.mulesoft.munit + mtf-tools + 1.0.0 + mule-plugin + test + +---- + +CAUTION: Metadata testing is available since Mule runtime engine 4.2.0. When running your tests against an earlier version, suites containing metadata tests are ignored. + +== Tooling Test + +The `tooling-test` component validates the module's metadata at design time, unlike the `munit:test` component that validates the module's metadata at execution. The `tooling-test` component is represented as follows: + +[source,xml,linenums] +---- + + ... + +---- + +When a suite with a tooling test runs, XML validations are disabled. When testing metadata, it might be necessary to avoid filling required parameters. + +The tooling test can have the following parameters: + +[%header%autowidth.spread,cols="a,a"] +|=== +|Name |Description + +|`name` +| Mandatory. Defines the name of the test. The name must be unique inside the test suite. + +|`description` +|Describes the scenario that is tested. + +|`ignore` +|Defines whether the test is ignored. If this parameter is not present, the test is not ignored. + +|`tags` +|Comma-separated list of tags to assign to the test. + +|`expectFailureCode` +|Defines the failure code that is received after the metadata calculation of this test. + +|`expectFailureMessage` +|Defines the failure message that is received after the metadata calculation of this test. + +|=== + +The tooling test has two main sections: + +* Metadata Scopes ++ +Wraps the component in which to calculate metadata and defines the metadata information to obtain. Possible values are: ++ +** Metadata keys +** Input metadata +** Output metadata +** Attributes metadata + +* Validation ++ +Contains all the validations regarding the result of the metadata scope. + +== Metadata Scopes + +Use metadata scopes in the tooling test. You can use only one metadata scope in each test. You can use either an operation or a source in each of these scopes. + +=== Metadata Keys + +The `metadata keys` scope obtains the metadata keys for the module. The `payload` contains a map, in which the key is the metadata key ID and the value is the metadata key: + +[source,xml,linenums] +---- + + + + + + + + +---- + +=== Input Metadata + +The `input metadata` scope obtains the metadata type for the specified parameter of the module. The `payload` contains a JSON representation of the metadata type: + +[source,xml,linenums] +---- + + + + + + + + +---- + +=== Output Metadata + +The `output metadata` obtains the metadata type for the output `payload` of the module. The `payload` contains a JSON representation of the metadata type: + +[source,xml,linenums] +---- + + + + + + + + + + + + +---- + +=== Attributes Metadata + +The `attributes metadata` scope obtains the metadata type for the `attributes` metadata of the module. The `payload` contains a JSON representation of the metadata type: + +[source,xml,linenums] +---- + + + + + + + + + + +---- + +The `mtf:get-values` element retrieves the possible values for the specified parameter of the module. The `payload` contains a JSON representation of the values. + +[source,xml,linenums] +---- + + + + + + + + + + +---- + +== Validation + +A common use case when testing metadata is validating failures that might occur during metadata calculation. To validate these failures, use the `expectFailureCode` and `expectFailureMessage` parameters: + +[source,xml,linenums] +---- + + + + + +---- + +=== Assert Type Processor + +Use the assert type processor to assert the metadata type structure returned by metadata scopes such as `get-input-metadata`, `get-output-metadata`, and `get-attributes-metadata`. + +The assert type processor compares the structure of both metadata types and ignores fields such as `format` or `annotations`. To perform assertions over these fields, you can use the `payload` result of the metadata scopes operations as shown in the previous examples. + +If the assertion fails, the processor throws a `java.lang.AssertionError` error. + +==== From Class + +To compare a metadata type structure with another metadata type structure obtained from a Java class, use the `fromClass` parameter: + +[source,xml,linenums] +---- + + + + + + + + +---- + +The `actual` field defaults to `payload`. You can choose to not specify the `actual` field. For example: + +[source,xml,linenums] +-- + +-- + +==== From Schema + +To compare a metadata type structure with another metadata type structure obtained from a schema, use the `fromSchema` parameter. + +The `fromSchema` parameter supports metadata types such as JSON schema, XSD schema, and RAML data types. The file extensions must be `.json`, `.xsd`, and `.raml` respectively and must be stored in the `src/test/resources` folder. + +[source,xml,linenums] +---- + + + + + + + + +---- + +The `actual` field defaults to `payload`. You can choose to not specify the `actual` field. For example: + +[source,xml,linenums] +-- + +-- + + The following examples provide a basic structure for testing the metadata defined for your module. == Prerequesites From a5e54a6bb570efe060d235ed465acf3f620c8c56 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 26 Oct 2023 12:37:09 -0700 Subject: [PATCH 22/53] more --- modules/ROOT/nav.adoc | 5 +- modules/ROOT/pages/metadata-testing.adoc | 244 ------------------ modules/ROOT/pages/mtf-metadata-testing.adoc | 10 +- modules/ROOT/pages/mtf-testing-examples.adoc | 3 +- ...extensions-maven-plugin-configuration.adoc | 2 +- 5 files changed, 6 insertions(+), 258 deletions(-) delete mode 100644 modules/ROOT/pages/metadata-testing.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 0a16ba06..5fabc9dd 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -88,12 +88,11 @@ *** xref:mtf-testing-examples.adoc[MTF Test Examples] **** xref:mtf-testing-sources.adoc[Sources] **** xref:mtf-expecting-errors.adoc[Expected Errors] - **** xref:mtf-metadata-testing.adoc[Metadata] **** xref:mtf-parameterized-tests.adoc[Parameterization] **** xref:mtf-using-test-classes.adoc[Classes] **** xref:testing-oauth-modules.adoc[OAuth Enabled Connectors] + **** xref:mtf-metadata-testing.adoc[Metadata] + **** xref:connectivity-testing.adoc[Connectivity] *** xref:munit-extensions-maven-plugin-configuration.adoc[Configuring the MUnit Extensions Maven Plugin] *** xref:munit-extensions-maven-plugin.adoc[Operating the MUnit Extensions Maven Plugin] - *** xref:metadata-testing.adoc[Metadata Testing] - *** xref:connectivity-testing.adoc[Connectivity Testing] ** xref:testing-writing-your-first-test-case.adoc[FlowRunner (Deprecated)] diff --git a/modules/ROOT/pages/metadata-testing.adoc b/modules/ROOT/pages/metadata-testing.adoc deleted file mode 100644 index fd810974..00000000 --- a/modules/ROOT/pages/metadata-testing.adoc +++ /dev/null @@ -1,244 +0,0 @@ -= Metadata Testing -ifndef::env-site,env-github[] -include::_attributes.adoc[] -endif::[] - -== Prerequisites - -. The following section assumes that you are already familiar on how to define `MetadataType` for your module. + -See xref:metadata.adoc[Adding DataSense Support] for more information. -. To create metadata tests you need to add the `mtf-tools` dependency to your project: -+ -[source,xml,linenums] ----- - - com.mulesoft.munit - mtf-tools - 1.0.0 - mule-plugin - test - ----- - -CAUTION: Metadata Testing is available since Mule Runtime version 4.2.0. When running your tests against a prior version, -suites containing metadata tests will be ignored. - - -== Tooling Test - -The `tooling-test` component is meant to validate the component's metadata at design time, unlike the `munit:test` that validates the component's execution. + -It has the following representation: - -[source,xml,linenums] ----- - - ... - ----- - -When a suite with tooling tests runs, XML validations are disabled. While testing metadata, it may be necessary to avoid filling required parameters. - -The tooling test can have the following parameters: - -[%header%autowidth.spread,cols="a,a"] -|=== -|Name |Description - -|`name` -| Mandatory. Defines the name of the test. The name must be unique inside the test suite. - -|`description` -|Describes the scenario being tested. - -|`ignore` -|Defines if the test should be ignored. If not present, the test is not ignored. - -|`tags` -|Comma separated list of tags to assign to the test. - -|`expectFailureCode` -|Defines the failure code that should be received after the metadata calculation of this test. - -|`expectFailureMessage` -|Defines the failure message that should be received after the metadata calculation of this test. - -|=== - -The tooling test has two main sections: - -* Metadata Scope: Wraps the component over which you need to calculate metadata, and defines the metadata information to obtain. + -Possible values are: -** Metadata Keys. -** Input Metadata. -** Output Metadata. -** Attributes Metadata. -* Validation: Has all the validations regarding the result of the metadata scope. - -== Metadata Scopes - -The following are scopes used inside the tooling test. Only one of them can be used in each test. + -You can use either an `operation` or a `source` in each of these scopes. - -=== Metadata Keys - -The `metadata keys` scope obtains the metadata keys for the component. The `payload` contains a map, where each key is the metadata key ID, and the value is the metadata key: - -[source,xml,linenums] ----- - - - - - - - - ----- - -=== Input Metadata - -The `input metadata` scope obtains the metadata type for the specified `parameter` of the component. The `payload` contains a JSON representation of the metadata type: - -[source,xml,linenums] ----- - - - - - - - - ----- - -=== Output Metadata - -The `output metadat` obtains the metadata type for the output `payload` of the component. The `payload` contains a JSON representation of the metadata type: - -[source,xml,linenums] ----- - - - - - - - - - - - - ----- - -=== Attributes Metadata - -The `attributes metadata` scope obtains the metadata type for the `attributes` metadata of the component. The `payload` contains a JSON representation of the metadata type: - -[source,xml,linenums] ----- - - - - - - - - - - ----- - -=== Get Values - -The `mtf:get-values` element retrieves the possible values for the specified `parameter` of the component. The `payload` contains a JSON representation of the values. - -[source,xml,linenums] ----- - - - - - - - - - - ----- - -== Expecting Failures - -A common use case when testing Metadata, is validating failures that may occur during metadata calculation. To validate these failures, you can use the `expectFailureCode` and `expectFailureMessage` parameters. - -[source,xml,linenums] ----- - - - - - ----- - -== Assert Type Processor - -The assert type processor allows you to assert the metadata type structure returned by metadata scopes such as `get-input-metadata`, `get-output-metadata` and `get-attributes-metadata`. - -The assert-type processor compares the structure of both metadata types, ignoring fields like `format` or `annotations`. To perform assertions over these fields, you can use the `payload` result of the metadata scopes operations as shown in the previous examples. - -If the assertion fails, the processor throws a `java.lang.AssertionError`. - -=== From Class - -To compare the metadata type structure against one obtained from a Java Class you use the `fromClass` parameter: - -[source,xml,linenums] ----- - - - - - - - - ----- - -The `actual` field defaults to `payload`. In the example above, you could choose not to specify it. For example: - -[source,xml,linenums] --- - --- - -=== From Schema - -To compare the metadata type structure against one obtained from a schema use the `fromSchema` parameter. - -The `fromSchema` supports metadata types from `JSON schema`, `XSD schema` and `RAML Data Types`. The file extensions need to be `.json`, `.xsd` and `.raml` respectively and stored in the `src/test/resources` folder. - -[source,xml,linenums] ----- - - - - - - - - ----- - - -The `actual` field defaults to `payload`. In the example above, you could choose not to specify it. For example: - -[source,xml,linenums] --- - --- - - -== See Also - diff --git a/modules/ROOT/pages/mtf-metadata-testing.adoc b/modules/ROOT/pages/mtf-metadata-testing.adoc index 49137a90..00c53886 100644 --- a/modules/ROOT/pages/mtf-metadata-testing.adoc +++ b/modules/ROOT/pages/mtf-metadata-testing.adoc @@ -7,7 +7,7 @@ Test the metadata defined for your module. == Prerequisites -* You must know how to define `MetadataType` for your module. For more information, refer to xref:metadata.adoc[Adding DataSense Support]. +* You must know how to define metadata in your module. For more information, refer to xref:metadata.adoc[Adding DataSense Support]. * To create metadata tests, you must add the `mtf-tools` dependency to your project: + [source,xml,linenums] @@ -238,14 +238,6 @@ The `actual` field defaults to `payload`. You can choose to not specify the `act -- - -The following examples provide a basic structure for testing the metadata defined for your module. - -== Prerequesites - -* You are familiar with how to define metadata in your module. + -See xref:metadata.adoc[Adding DataSense Support] and xref:metadata-testing.adoc[Metadata Testing] for more information. - == Example Implementations provided in the following example use fixed values to simplify the code. You must obtain metadata through external services. diff --git a/modules/ROOT/pages/mtf-testing-examples.adoc b/modules/ROOT/pages/mtf-testing-examples.adoc index 1ec55fe1..24891dff 100644 --- a/modules/ROOT/pages/mtf-testing-examples.adoc +++ b/modules/ROOT/pages/mtf-testing-examples.adoc @@ -10,8 +10,9 @@ Here are some examples of tests that demonstrate common uses, patterns, and best | Example | Description | xref:mtf-testing-sources.adoc[Sources] | Learn how different types of sources require different types of testing approaches. | xref:mtf-expecting-errors.adoc[Expected Errors] | Validate that your module throws the proper errors. -| xref:mtf-metadata-testing.adoc[Metadata] | Test your module's metadata. | xref:mtf-parameterized-tests.adoc[Parameterization] | Use parameterization to reuse your tests. | xref:mtf-using-test-classes.adoc[Classes] | Use auxiliary classes for your tests. | xref:testing-oauth-modules.adoc[OAuth Enabled Modules] | Test modules that use OAuth authentication. +| xref:mtf-metadata-testing.adoc[Metadata] | Test your module's metadata. +| xref:connectivity-testing.adoc[Connectivity] | Test your module's connectivity. |=== \ No newline at end of file diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc index 8dc2bdf6..0ae0c5b2 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc @@ -1,4 +1,4 @@ -= MUnit Extensions Maven Plugin Configuration += Configuring the MUnit Extensions Maven Plugin ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] From 7ce9499160b3538e493d0e68af97b876f36a29a8 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 26 Oct 2023 12:40:33 -0700 Subject: [PATCH 23/53] Update mtf-metadata-testing.adoc --- modules/ROOT/pages/mtf-metadata-testing.adoc | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/modules/ROOT/pages/mtf-metadata-testing.adoc b/modules/ROOT/pages/mtf-metadata-testing.adoc index 00c53886..a31270d5 100644 --- a/modules/ROOT/pages/mtf-metadata-testing.adoc +++ b/modules/ROOT/pages/mtf-metadata-testing.adoc @@ -242,9 +242,9 @@ The `actual` field defaults to `payload`. You can choose to not specify the `act Implementations provided in the following example use fixed values to simplify the code. You must obtain metadata through external services. -Your module can define the following metadata: +This module defines the following metadata: -.Operation with Metadata +.Operation with metadata [source, java, linenums] ---- @OutputResolver(output = ExampleOutputResolver.class) @@ -306,7 +306,6 @@ public class ExampleOutputResolver implements OutputTypeResolver { The following example validates that the keys have the proper `Display` names: -.Tooling test to validate metadata keys [source, xml, linenums] ---- @@ -322,9 +321,8 @@ The following example validates that the keys have the proper `Display` names: == Validating a Metadata Type -The following test validates the `Metadata Type` value returned by the operation: +The following test validates the `Metadata Type` output value returned by the operation: -.Tooling Test to Validate the Output Metadata Type of an Operation [source, xml, linenums] ---- @@ -347,7 +345,6 @@ In the previous example, the module throws a `MetadataResolvingException` error The following test validates that the proper failure code and message are thrown when the parameter is invalid: -.Tooling test to validate metadata failures [source, xml, linenums] ---- Date: Thu, 26 Oct 2023 12:55:35 -0700 Subject: [PATCH 24/53] more --- .../ROOT/pages/mtf-parameterized-tests.adoc | 14 +++++-------- .../ROOT/pages/mtf-using-test-classes.adoc | 20 ++++++------------- 2 files changed, 11 insertions(+), 23 deletions(-) diff --git a/modules/ROOT/pages/mtf-parameterized-tests.adoc b/modules/ROOT/pages/mtf-parameterized-tests.adoc index b76f9968..c7f76ec8 100644 --- a/modules/ROOT/pages/mtf-parameterized-tests.adoc +++ b/modules/ROOT/pages/mtf-parameterized-tests.adoc @@ -1,15 +1,14 @@ -= Parameterized Test += Parameterization ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -A parameterized suite allows you to run the same tests with different inputs. See xref:munit::munit-parameterized-suite.adoc[MUnit Parameterized Test Suite] for more information. +Use a parameterized suite to run the same tests with different inputs. For more information, refer to xref:munit::munit-parameterized-suite.adoc[MUnit Parameterized Test Suite]. == Configuration Parameterization Example -The following example shows a test suite with two parameterizations, each of them pointing to a different configuration: +The following example shows a test suite with two parameterizations, each pointing to a different configuration: -.Operation with a config [source, java, linenums] ---- public Integer withConfig(@Config ExampleConfig config) { @@ -19,7 +18,6 @@ public Integer withConfig(@Config ExampleConfig config) { You can test different configurations as follows: -.Test that runs against different configurations [source, xml, linenums] ---- @@ -54,9 +52,8 @@ You can test different configurations as follows: == Input Data Parameterization Example -Suppose that you want to execute one operation but with different inputs, each with different expected outputs: for example, testing an operation that replaces one string input with another. Your operation uses the following syntax: +Suppose you want to execute one operation but with different inputs, and each input has different expected outputs. For example, testing an operation that replaces one string input with another. Your operation uses the following syntax: -.Operation for Different Inputs [source, java, linenums] ---- public String replace(String input, String toReplace, String replacement) { @@ -64,9 +61,8 @@ public String replace(String input, String toReplace, String replacement) { } ---- -Your test for several different inputs to one operation looks like this: +Your test for several different inputs for one operation looks like this: -.Test Case with Different Inputs [source, xml, linenums] ---- diff --git a/modules/ROOT/pages/mtf-using-test-classes.adoc b/modules/ROOT/pages/mtf-using-test-classes.adoc index 41e61a14..a572be75 100644 --- a/modules/ROOT/pages/mtf-using-test-classes.adoc +++ b/modules/ROOT/pages/mtf-using-test-classes.adoc @@ -1,13 +1,12 @@ -= Using Test Classes += Classes ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -When developing test cases, you might want to use Java classes located in `src/test/java`. You can use Java classes through Java Module or through DataWeave. +When creating test cases, you can use Java classes located in `src/test/java`. You can use Java classes through DataWeave or through Java Module. For the following example, assume that your class is located in `src/test/java/com/example/MyUtilClass.java`: -.MyUtilClass [source, java, linenums] ---- package com.example.test; @@ -17,15 +16,13 @@ public class Helper { public static long getCurrentMillis() { return System.currentTimeMillis(); } - } ---- == Using DataWeave -To invoke static methods using DataWeave you must add the `java!` prefix to the package name of the class: +To invoke static methods using DataWeave, you must add the `java!` prefix to the package name of the class: -.Using a Class in DataWeave [source, xml, linenums] ---- @@ -40,9 +37,8 @@ To invoke static methods using DataWeave you must add the `java!` prefix to the == Using Java Module -. Ensure that the Java module is in your project: +. Ensure that Java Module is in your project: + -.Java Module dependency [source, xml, linenums] ---- @@ -53,10 +49,8 @@ To invoke static methods using DataWeave you must add the `java!` prefix to the test ---- -. Use any of the Java Module's operations. + -In this case, invoke a static method of a class: +. Use any of the operations in Java Module. In this case, invoke a static method of a class: + -.Using a class with the Java Module [source, xml, linenums] ---- @@ -69,9 +63,7 @@ In this case, invoke a static method of a class: ---- -MUnit Extensions Maven Plugin automatically exports any test packages and test resources in your -project. If your module is already exporting a class located in `src/main/java`, then any test classes with the same package -located in `src/test/java` won't be exported because this would cause a conflict. To be able to export both classes, you must change the test classes to a different package. +The MUnit Extensions Maven Plugin automatically exports any test packages and test resources in your project. If your module already exports a class located in `src/main/java`, then any test classes with the same package located in `src/test/java` are not exported because this causes a conflict. To export both classes, you must change the test classes to a different package. From 85e61176a53833fef599ca1eba0393e01087a9c9 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 26 Oct 2023 15:10:31 -0700 Subject: [PATCH 25/53] Update mtf-metadata-testing.adoc --- modules/ROOT/pages/mtf-metadata-testing.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/modules/ROOT/pages/mtf-metadata-testing.adoc b/modules/ROOT/pages/mtf-metadata-testing.adoc index a31270d5..bf457c41 100644 --- a/modules/ROOT/pages/mtf-metadata-testing.adoc +++ b/modules/ROOT/pages/mtf-metadata-testing.adoc @@ -302,7 +302,7 @@ public class ExampleOutputResolver implements OutputTypeResolver { } ---- -== Validating Metadata Keys +== Testing Metadata Keys The following example validates that the keys have the proper `Display` names: @@ -319,7 +319,7 @@ The following example validates that the keys have the proper `Display` names: ---- -== Validating a Metadata Type +== Testing a Metadata Type The following test validates the `Metadata Type` output value returned by the operation: @@ -339,7 +339,7 @@ The following test validates the `Metadata Type` output value returned by the op ---- -== Validating an Expected Failure +== Testing an Expected Failure In the previous example, the module throws a `MetadataResolvingException` error when the parameter is null or empty. From cbb5078e1a316dffbbb1111e587640a8d16b6f95 Mon Sep 17 00:00:00 2001 From: sathya0 <78386709+sathya0@users.noreply.github.com> Date: Fri, 27 Oct 2023 10:42:08 -0700 Subject: [PATCH 26/53] Update modules/ROOT/pages/mtf-testing-sources.adoc Co-authored-by: Cristian-Venticinque <46459586+Cristian-Venticinque@users.noreply.github.com> --- modules/ROOT/pages/mtf-testing-sources.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/mtf-testing-sources.adoc b/modules/ROOT/pages/mtf-testing-sources.adoc index 86890f87..fa40ebd1 100644 --- a/modules/ROOT/pages/mtf-testing-sources.adoc +++ b/modules/ROOT/pages/mtf-testing-sources.adoc @@ -9,7 +9,7 @@ There are several types of sources, each with its own distinct testing strategy. == Sources That Emit a Response -The most common type of test is when the source generates a synchronous response. To test a source that emits a response, you must trigger the source to get that response, and then assert it. +The most common type of test is when the source generates a synchronous response. To test a source that emits a response, trigger the source to get that response, and then assert it. For example, in the case of `http:listener`, you can trigger the source with `http:request`: From b8596620a90d07c87cead6a0130b7b84e207cd19 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Mon, 30 Oct 2023 08:32:35 -0700 Subject: [PATCH 27/53] Update mtf-parameterized-tests.adoc --- modules/ROOT/pages/mtf-parameterized-tests.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/mtf-parameterized-tests.adoc b/modules/ROOT/pages/mtf-parameterized-tests.adoc index c7f76ec8..0f020985 100644 --- a/modules/ROOT/pages/mtf-parameterized-tests.adoc +++ b/modules/ROOT/pages/mtf-parameterized-tests.adoc @@ -3,7 +3,7 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -Use a parameterized suite to run the same tests with different inputs. For more information, refer to xref:munit::munit-parameterized-suite.adoc[MUnit Parameterized Test Suite]. +Use a parameterized suite to run the same tests with different inputs. For more information, refer to xref:munit::munit-parameterized.adoc[MUnit Parameterized Test Suite]. == Configuration Parameterization Example From 56981009e3312c44585ba48a8ed5b25a37a26922 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Mon, 30 Oct 2023 13:31:47 -0700 Subject: [PATCH 28/53] more --- modules/ROOT/nav.adoc | 2 +- modules/ROOT/pages/mtf-testing-examples.adoc | 2 +- modules/ROOT/pages/testing-oauth-modules.adoc | 22 +++++++++---------- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 5fabc9dd..fa2da8bc 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -90,7 +90,7 @@ **** xref:mtf-expecting-errors.adoc[Expected Errors] **** xref:mtf-parameterized-tests.adoc[Parameterization] **** xref:mtf-using-test-classes.adoc[Classes] - **** xref:testing-oauth-modules.adoc[OAuth Enabled Connectors] + **** xref:testing-oauth-modules.adoc[OAuth-Enabled Modules] **** xref:mtf-metadata-testing.adoc[Metadata] **** xref:connectivity-testing.adoc[Connectivity] *** xref:munit-extensions-maven-plugin-configuration.adoc[Configuring the MUnit Extensions Maven Plugin] diff --git a/modules/ROOT/pages/mtf-testing-examples.adoc b/modules/ROOT/pages/mtf-testing-examples.adoc index 24891dff..d62bdf29 100644 --- a/modules/ROOT/pages/mtf-testing-examples.adoc +++ b/modules/ROOT/pages/mtf-testing-examples.adoc @@ -12,7 +12,7 @@ Here are some examples of tests that demonstrate common uses, patterns, and best | xref:mtf-expecting-errors.adoc[Expected Errors] | Validate that your module throws the proper errors. | xref:mtf-parameterized-tests.adoc[Parameterization] | Use parameterization to reuse your tests. | xref:mtf-using-test-classes.adoc[Classes] | Use auxiliary classes for your tests. -| xref:testing-oauth-modules.adoc[OAuth Enabled Modules] | Test modules that use OAuth authentication. +| xref:testing-oauth-modules.adoc[OAuth-Enabled Modules] | Test modules that use OAuth authentication. | xref:mtf-metadata-testing.adoc[Metadata] | Test your module's metadata. | xref:connectivity-testing.adoc[Connectivity] | Test your module's connectivity. |=== \ No newline at end of file diff --git a/modules/ROOT/pages/testing-oauth-modules.adoc b/modules/ROOT/pages/testing-oauth-modules.adoc index 7a36ee82..25d475df 100644 --- a/modules/ROOT/pages/testing-oauth-modules.adoc +++ b/modules/ROOT/pages/testing-oauth-modules.adoc @@ -1,18 +1,18 @@ -= Testing OAuth-Enabled Connectors += OAuth-Enabled Modules ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -Mule runtime engine supports authorization through various OAuth grant types, including `Authorization Code`. This grant type allows an external system (for example, your Mule application) to operate on behalf of a user without requiring user authentication. +Mule runtime engine supports authorization through various OAuth grant types, including the Authorization Code grant type, which allows an external system (for example, your Mule application) to operate on behalf of a user without requiring user authentication. -However, because the `Authorization Code` grant type is designed to force human intervention in the authentication process that identifies users using OAuth (OAuth dance), building an automated test for an application using this grant type is challenging. +However, because the Authorization Code grant type is designed to force human intervention in the authentication process that identifies users using OAuth (OAuth dance), building an automated test for an application using this grant type is challenging. -To overcome this challenge, you can use the Storage Event processor to bypass the OAuth dance by manually providing a valid access token. Note the following requirements: +To overcome this challenge, you can use the Storage Event processor to bypass the OAuth dance by manually providing a valid access token. Ensure the following requirements are met: -* It is your responsibility to manually obtain the token. -* It is your responsibility to be aware that the token will eventually expire. + +* You must manually obtain the token. +* You must be aware that the token eventually expires. + How often the token expires depends on the service provider to which you are connecting. -* It is your responsibility to obtain a new token and update the test with it. +* You must obtain a new token and update the test with it. == Example @@ -34,9 +34,9 @@ Consider the following configuration of Salesforce Connector using OAuth authent ---- <1> The application defines an object store named `tokenStore`. -<2> It uses the `tokenStore` object store to store the OAuth token. +<2> The application uses the `tokenStore` object store to store the OAuth token. -To use the token stored in `tokenStore` in an MUnit test, create a flow and insert your token in an MUnit Storage Event processor: +To use the OAuth token stored in `tokenStore` in an MUnit test, create a flow and insert your token in an MUnit Storage Event processor: [source,xml,linenums] ---- @@ -54,9 +54,9 @@ To use the token stored in `tokenStore` in an MUnit test, create a flow and inse ---- -Note that the `ownerConfigName` element matches the name of the Salesforce configuration. The access token and other properties shown here are placeholders for the values that you obtain by manually performing the OAuth dance. Then you supply the token to the test via system properties, a properties file, or whatever mechanism you choose. +Note that the `ownerConfigName` element matches the name of the Salesforce configuration. The access token and other properties shown here are placeholders for the values that you obtain by manually performing the OAuth dance. You can then supply the token to the MUnit test through system properties, a properties file, or any other mechanism you choose. -After you supply the token values, your Munit test has the following structure: +After you supply the token values, your MUnit test has the following structure: [source,xml,linenums] ---- From 92e12277a89cd093a6c9e0e8841a6e7caa4ce0e8 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Mon, 30 Oct 2023 13:46:23 -0700 Subject: [PATCH 29/53] more --- modules/ROOT/pages/connectivity-testing.adoc | 30 ++++++++------------ modules/ROOT/pages/mtf-expecting-errors.adoc | 2 +- modules/ROOT/pages/mtf-metadata-testing.adoc | 2 +- 3 files changed, 14 insertions(+), 20 deletions(-) diff --git a/modules/ROOT/pages/connectivity-testing.adoc b/modules/ROOT/pages/connectivity-testing.adoc index 07ce103c..d9b862df 100644 --- a/modules/ROOT/pages/connectivity-testing.adoc +++ b/modules/ROOT/pages/connectivity-testing.adoc @@ -1,13 +1,14 @@ -== Connectivity Testing += Connectivity ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -== Prerequisites +Test the connectivity defined for your module. -* Be familiar with how to define a connection for your module. + -See xref:connections.adoc[Connections] for more information. -* To create connectivity tests, add the `mtf-tools` dependency to your project: +== Before You Begin + +* You must know how to define a connection for your module. For more information, refer to xref:connections.adoc[Connections]. +* To create connectivity tests, you must add the `mtf-tools` dependency to your project: + [source,xml,linenums] ---- @@ -19,20 +20,17 @@ See xref:connections.adoc[Connections] for more information. test ---- -* Connectivity Testing is available since Mule Runtime version 4.2.0. + -If your connector has a minMuleVersion prior to 4.2.0, add the `minMuleVersion` to your connectivity testing suite: `` +CAUTION: Connectivity testing is available since Mule runtime engine 4.2.0. If your module has a minimum Mule version earlier than 4.2.0, add `minMuleVersion` to your connectivity testing suite, for example: `` -== Test Connectivity +== Testing Connectivity -The `test-connectivity` processor establishes a connection using the given configuration. If testing connectivity with the given configuration fails, the processor will fail with the proper exception, description -and error type (if present), +The `test-connectivity` processor establishes a connection using the given configuration. If testing connectivity with the given configuration fails, the processor fails with the proper exception, description, and error type (if present). === Successful Connection When you test that a connection is valid, you are validating that the processor does not fail. A successful connection test looks as follows: -.Valid connection [source,xml,linenums] ---- @@ -42,11 +40,10 @@ When you test that a connection is valid, you are validating that the processor ---- -=== Invalid connection +=== Invalid Connection -When a connection fails, the processor fails. Therefore, to test an invalid connection, expect the error in the test: +When a connection fails, the processor fails. Therefore, to test an invalid connection, include an expected exception and expected error description in the test: -.Invalid connection [source,xml,linenums] ---- ---- -If the connection fails with an error type, you can expect it as well: +If the connection fails with an error type, you can include an expected error type as well: -.Invalid connection with error type [source,xml,linenums] ---- Date: Mon, 30 Oct 2023 16:25:53 -0700 Subject: [PATCH 30/53] Update connectivity-testing.adoc --- modules/ROOT/pages/connectivity-testing.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/connectivity-testing.adoc b/modules/ROOT/pages/connectivity-testing.adoc index d9b862df..7ea13385 100644 --- a/modules/ROOT/pages/connectivity-testing.adoc +++ b/modules/ROOT/pages/connectivity-testing.adoc @@ -21,7 +21,7 @@ Test the connectivity defined for your module. ---- -CAUTION: Connectivity testing is available since Mule runtime engine 4.2.0. If your module has a minimum Mule version earlier than 4.2.0, add `minMuleVersion` to your connectivity testing suite, for example: `` +CAUTION: Connectivity testing is available since Mule runtime engine 4.2.0. If your module has a minimum Mule version earlier than 4.2.0, add `minMuleVersion` to your connectivity testing suite, for example: ``. == Testing Connectivity From e7e84bf3b7a4ef5eadd87a408efa4e78f8993e90 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 2 Nov 2023 12:55:56 -0700 Subject: [PATCH 31/53] Update munit-extensions-maven-plugin-configuration.adoc --- ...extensions-maven-plugin-configuration.adoc | 59 +++++++------------ 1 file changed, 21 insertions(+), 38 deletions(-) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc index 0ae0c5b2..6800ca35 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc @@ -3,12 +3,12 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -== Additional argument lines +The MUnit Extensions Maven plugin provides testing capabilities for extension development. Learn how to configure the MUnit Extensions Maven plugin to test your modules. -Since the tests are being run in a new JVM, additional argument lines can be specified -to the JVM. Each argument should be specified in separate `argLine`. +== Specifying Additional Argument Lines + +Since you run the tests in a new JVM, you can specify additional argument lines to the JVM. Specify each argument in a separate `argLine`. -.Argument lines [source,xml,linenums] ---- @@ -27,14 +27,13 @@ to the JVM. Each argument should be specified in separate `argLine`. ---- -== To Enable Runtime Discovery +== Enabling Runtime Discovery -Runtime Discovery looks for all runtime versions published on nexus, to run +Runtime discovery looks for all Mule runtime versions published on Nexus to run against your tests. -To enable MUnit Runtime Discovery, add the following configuration to the MUnit Plugin: +To enable runtime discovery, add the following configuration to the MUnit Extensions Maven plugin: -.MUnit Runtime Discovery [source,xml,linenums] ---- @@ -53,18 +52,16 @@ To enable MUnit Runtime Discovery, add the following configuration to the MUnit ---- -<1> This enables the runtime discovery feature for all released CE runtimes +<1> This enables the runtime discovery feature for all released CE runtimes. From the command line, the property is `discoverRuntimes.product`. -NOTE: Product can be CE, EE or ALL (both CE and EE) +NOTE: The `product` can be CE (Community Edition), EE (Enterprise Edition), or ALL (both CE and EE). -=== To Include Snapshots +=== Including Snapshots -If you want to include snapshot versions of the runtime you can add the following -line to the runtime configuration: +To include snapshot versions of Mule runtime, add the following line to the runtime configuration: -.MUnit Runtime Discovery - Include Snapshots [source,xml,linenums] ---- @@ -75,15 +72,12 @@ line to the runtime configuration: ---- -From the command line, the property is `discoverRuntimes.includeSnapshots`. - -Default value is `false`. +From the command line, the property is `discoverRuntimes.includeSnapshots`. The default value is `false`. === Discovering Only the Latest Patches -If you want to discover only the latest patch versions of Mule runtime engine, add the following line to the runtime configuration: +To discover only the latest patch versions of Mule runtime, add the following line to the runtime configuration: -.MUnit Runtime Discovery - Include Latest Patches [source,xml,linenums] ---- @@ -94,15 +88,12 @@ If you want to discover only the latest patch versions of Mule runtime engine, a ---- -From the command line, the property is `discoverRuntimes.latestPatches`. - -Default value is `true`. +From the command line, the property is `discoverRuntimes.latestPatches`. The default value is `true`. === Discovering Since a Minimum Version -By default, the runtime discovery searches for all Mule runtime engine versions since the `minMuleVersion` of the module. You can change this minimum version adding the following to the runtime configuration: +By default, runtime discovery searches for all Mule runtime versions since the `minMuleVersion` of the module. To change this minimum version, add the following line to the runtime configuration: -.MUnit Runtime Discovery - Minimum Version [source,xml,linenums] ---- @@ -113,17 +104,12 @@ By default, the runtime discovery searches for all Mule runtime engine versions ---- -From the command line, the property is `discoverRuntimes.minMuleVersion`. +From the command line, the property is `discoverRuntimes.minMuleVersion`. The default value is the `minMuleVersion` of the module. -Default value is the `minMuleVersion` of the module. +=== Running Against Additional Runtimes -=== To Run Against Additional Runtimes +By default, the MUnit Extensions Maven plugin runs against the `minMuleVersion` and the required product of the module. To specify additional runtimes to run against, add the following lines to the runtime configuration: -By default, the plugin runs against the minMuleVersion and the required product of the module. -If you want to specify additional runtimes to run against, you can add the following to the runtime -configuration: - -.MUnit Runtime Configuration - Additional Runtimes [source,xml,linenums] ---- @@ -136,11 +122,10 @@ configuration: From the command line, the property is `additionalRuntimes`. -=== To Skip Runtime Discovery +=== Skipping Runtime Discovery -If you wish to skip runtime discovery, you can add the following line to the runtime configuration: +To skip runtime discovery, add the following line to the runtime configuration: -.MUnit Runtime Discovery - Include Snapshots [source,xml,linenums] ---- @@ -151,9 +136,7 @@ If you wish to skip runtime discovery, you can add the following line to the run ---- -From the command line, the property is `discoverRuntimes.skip`. - -Default value is `false`. +From the command line, the property is `discoverRuntimes.skip`. The default value is `false`. == Dynamic Ports From de3c1fc9b3281cee4b020649e2174ed79fee848a Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 2 Nov 2023 13:28:53 -0700 Subject: [PATCH 32/53] Update munit-extensions-maven-plugin-configuration.adoc --- .../pages/munit-extensions-maven-plugin-configuration.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc index 6800ca35..f0411df6 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc @@ -138,7 +138,7 @@ To skip runtime discovery, add the following line to the runtime configuration: From the command line, the property is `discoverRuntimes.skip`. The default value is `false`. -== Dynamic Ports +== Using Dynamic Ports [IMPORTANT] MUnit 2.2 and later introduce the `dynamic-port` global element, that allows you to define dynamic ports at the MUnit suite level. + @@ -557,4 +557,4 @@ If any of the suite files or resources are not present in the classpath, the plu == See Also -* xref:munit-extensions-maven-plugin.adoc[MUnit Extensions Maven Plugin] +* xref:munit-extensions-maven-plugin.adoc[] From 6d8e8fc632b78a377cecc85e7b41d5948015f4e9 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 9 Nov 2023 10:09:38 -0800 Subject: [PATCH 33/53] editorial --- modules/ROOT/pages/mtf-expecting-errors.adoc | 16 ++++++++-------- modules/ROOT/pages/mtf-parameterized-tests.adoc | 12 ++++++------ 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/modules/ROOT/pages/mtf-expecting-errors.adoc b/modules/ROOT/pages/mtf-expecting-errors.adoc index a61a5a5f..beba7438 100644 --- a/modules/ROOT/pages/mtf-expecting-errors.adoc +++ b/modules/ROOT/pages/mtf-expecting-errors.adoc @@ -7,11 +7,11 @@ Validate the error types and error descriptions that your module throws. == Before You Begin -* You must know how to define the errors that your module throws. For more information, refer to xref:errors.adoc[Errors Definition]. +You must know how to define the errors that your module throws. For more information, refer to xref:errors.adoc[]. -== Example +== Example: Error Definition -Suppose there is a module that defines errors as follows: +In this example, the module defines errors as follows: .Error type definition [source,java,linenums] @@ -46,11 +46,11 @@ public void execute(Integer number) { } ---- -You can create tests to validate the expected error type and error description. +Use MTF to create tests to validate the expected error type and error description. -== Validating an Expected Error Type +== Validate an Expected Error Type -You can validate that the error thrown by the module in the example has the proper error type as follows: +To validate that the error thrown by the module in the example has the proper error type: [source, xml, linenums] ---- @@ -61,9 +61,9 @@ You can validate that the error thrown by the module in the example has the prop ---- -== Validating an Expected Error Description +== Validate an Expected Error Description -You can validate that the error thrown by the module in the example has the proper error description as follows: +To validate that the error thrown by the module in the example has the proper error description: [source, xml, linenums] ---- diff --git a/modules/ROOT/pages/mtf-parameterized-tests.adoc b/modules/ROOT/pages/mtf-parameterized-tests.adoc index 0f020985..0ed81ef8 100644 --- a/modules/ROOT/pages/mtf-parameterized-tests.adoc +++ b/modules/ROOT/pages/mtf-parameterized-tests.adoc @@ -3,9 +3,9 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -Use a parameterized suite to run the same tests with different inputs. For more information, refer to xref:munit::munit-parameterized.adoc[MUnit Parameterized Test Suite]. +Use a parameterized suite to run the same tests with different inputs. For more information, refer to xref:munit::parameterized.adoc[]. -== Configuration Parameterization Example +== Example: Configuration Parameterization The following example shows a test suite with two parameterizations, each pointing to a different configuration: @@ -16,7 +16,7 @@ public Integer withConfig(@Config ExampleConfig config) { } ---- -You can test different configurations as follows: +Use the following code to test different configurations: [source, xml, linenums] ---- @@ -50,9 +50,9 @@ You can test different configurations as follows: ---- -== Input Data Parameterization Example +== Example: Input Data Parameterization -Suppose you want to execute one operation but with different inputs, and each input has different expected outputs. For example, testing an operation that replaces one string input with another. Your operation uses the following syntax: +Suppose you want to execute one operation but with different inputs, and each input has different expected outputs. For example, testing an operation that replaces one string input with another. Use the following syntax for your operation: [source, java, linenums] ---- @@ -61,7 +61,7 @@ public String replace(String input, String toReplace, String replacement) { } ---- -Your test for several different inputs for one operation looks like this: +Use the following code to test for several different inputs for one operation: [source, xml, linenums] ---- From 21a3ef39873b0e29b477ee12f619c0fda12f9f2c Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 9 Nov 2023 10:53:05 -0800 Subject: [PATCH 34/53] more --- modules/ROOT/pages/mtf-metadata-testing.adoc | 4 ++-- modules/ROOT/pages/mtf-using-test-classes.adoc | 16 +++++++++------- modules/ROOT/pages/testing-oauth-modules.adoc | 4 ++-- 3 files changed, 13 insertions(+), 11 deletions(-) diff --git a/modules/ROOT/pages/mtf-metadata-testing.adoc b/modules/ROOT/pages/mtf-metadata-testing.adoc index e7be5128..9e978295 100644 --- a/modules/ROOT/pages/mtf-metadata-testing.adoc +++ b/modules/ROOT/pages/mtf-metadata-testing.adoc @@ -7,8 +7,8 @@ Test the metadata defined for your module. == Before You Begin -* You must know how to define metadata in your module. For more information, refer to xref:metadata.adoc[Adding DataSense Support]. -* To create metadata tests, you must add the `mtf-tools` dependency to your project: +* Know how to define metadata in your module. For more information, refer to xref:metadata.adoc[]. +* To create metadata tests, add the `mtf-tools` dependency to your project: + [source,xml,linenums] ---- diff --git a/modules/ROOT/pages/mtf-using-test-classes.adoc b/modules/ROOT/pages/mtf-using-test-classes.adoc index a572be75..b81d8c0b 100644 --- a/modules/ROOT/pages/mtf-using-test-classes.adoc +++ b/modules/ROOT/pages/mtf-using-test-classes.adoc @@ -3,9 +3,9 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -When creating test cases, you can use Java classes located in `src/test/java`. You can use Java classes through DataWeave or through Java Module. +When creating test cases, use Java classes located in `src/test/java`. Use Java classes through DataWeave or through Java Module. -For the following example, assume that your class is located in `src/test/java/com/example/MyUtilClass.java`: +In the following example, assume that your class is located in `src/test/java/com/example/MyUtilClass.java`: [source, java, linenums] ---- @@ -19,9 +19,9 @@ public class Helper { } ---- -== Using DataWeave +== Use Classes Through DataWeave -To invoke static methods using DataWeave, you must add the `java!` prefix to the package name of the class: +To invoke static methods using DataWeave, add the `java!` prefix to the package name of the class: [source, xml, linenums] ---- @@ -35,7 +35,9 @@ To invoke static methods using DataWeave, you must add the `java!` prefix to the ---- -== Using Java Module +== Use Classes Through Java Module + +To use classes through Java Module: . Ensure that Java Module is in your project: + @@ -49,7 +51,7 @@ To invoke static methods using DataWeave, you must add the `java!` prefix to the test ---- -. Use any of the operations in Java Module. In this case, invoke a static method of a class: +. Use any of the operations in Java Module. In this example, invoke a static method of a class: + [source, xml, linenums] ---- @@ -63,7 +65,7 @@ To invoke static methods using DataWeave, you must add the `java!` prefix to the ---- -The MUnit Extensions Maven Plugin automatically exports any test packages and test resources in your project. If your module already exports a class located in `src/main/java`, then any test classes with the same package located in `src/test/java` are not exported because this causes a conflict. To export both classes, you must change the test classes to a different package. +The MUnit Extensions Maven Plugin automatically exports any test packages and test resources in your project. If your module already exports a class located in `src/main/java`, then any test classes with the same package located in `src/test/java` are not exported because this causes a conflict. To export both classes, change the test classes to a different package. diff --git a/modules/ROOT/pages/testing-oauth-modules.adoc b/modules/ROOT/pages/testing-oauth-modules.adoc index 25d475df..069907a7 100644 --- a/modules/ROOT/pages/testing-oauth-modules.adoc +++ b/modules/ROOT/pages/testing-oauth-modules.adoc @@ -7,14 +7,14 @@ Mule runtime engine supports authorization through various OAuth grant types, in However, because the Authorization Code grant type is designed to force human intervention in the authentication process that identifies users using OAuth (OAuth dance), building an automated test for an application using this grant type is challenging. -To overcome this challenge, you can use the Storage Event processor to bypass the OAuth dance by manually providing a valid access token. Ensure the following requirements are met: +To overcome this challenge, use the Storage Event processor to bypass the OAuth dance by manually providing a valid access token. Ensure the following requirements are met: * You must manually obtain the token. * You must be aware that the token eventually expires. + How often the token expires depends on the service provider to which you are connecting. * You must obtain a new token and update the test with it. -== Example +== Example: OAuth-Enabled Module Consider the following configuration of Salesforce Connector using OAuth authentication: From 698847bfb247c265d0a5629e36e5a5af59d30960 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 9 Nov 2023 12:39:47 -0800 Subject: [PATCH 35/53] more --- modules/ROOT/pages/connectivity-testing.adoc | 6 +++--- modules/ROOT/pages/mtf-metadata-testing.adoc | 8 ++++---- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/modules/ROOT/pages/connectivity-testing.adoc b/modules/ROOT/pages/connectivity-testing.adoc index 7ea13385..71bb64d0 100644 --- a/modules/ROOT/pages/connectivity-testing.adoc +++ b/modules/ROOT/pages/connectivity-testing.adoc @@ -7,8 +7,8 @@ Test the connectivity defined for your module. == Before You Begin -* You must know how to define a connection for your module. For more information, refer to xref:connections.adoc[Connections]. -* To create connectivity tests, you must add the `mtf-tools` dependency to your project: +* Know how to define a connection for your module. For more information, refer to xref:connections.adoc[]. +* To create connectivity tests, add the `mtf-tools` dependency to your project: + [source,xml,linenums] ---- @@ -23,7 +23,7 @@ Test the connectivity defined for your module. CAUTION: Connectivity testing is available since Mule runtime engine 4.2.0. If your module has a minimum Mule version earlier than 4.2.0, add `minMuleVersion` to your connectivity testing suite, for example: ``. -== Testing Connectivity +== Test Connectivity The `test-connectivity` processor establishes a connection using the given configuration. If testing connectivity with the given configuration fails, the processor fails with the proper exception, description, and error type (if present). diff --git a/modules/ROOT/pages/mtf-metadata-testing.adoc b/modules/ROOT/pages/mtf-metadata-testing.adoc index 9e978295..b66d0140 100644 --- a/modules/ROOT/pages/mtf-metadata-testing.adoc +++ b/modules/ROOT/pages/mtf-metadata-testing.adoc @@ -238,7 +238,7 @@ The `actual` field defaults to `payload`. You can choose to not specify the `act -- -== Example +== Example: Metadata Test Implementations provided in the following example use fixed values to simplify the code. You must obtain metadata through external services. @@ -302,7 +302,7 @@ public class ExampleOutputResolver implements OutputTypeResolver { } ---- -== Testing Metadata Keys +== Test Metadata Keys The following example validates that the keys have the proper `Display` names: @@ -319,7 +319,7 @@ The following example validates that the keys have the proper `Display` names: ---- -== Testing a Metadata Type +== Test a Metadata Type The following test validates the `Metadata Type` output value returned by the operation: @@ -339,7 +339,7 @@ The following test validates the `Metadata Type` output value returned by the op ---- -== Testing an Expected Failure +== Test an Expected Failure In the previous example, the module throws a `MetadataResolvingException` error when the parameter is null or empty. From fea1b2cad2f286a546a23beb1cf07bf45756774e Mon Sep 17 00:00:00 2001 From: sathya0 Date: Thu, 9 Nov 2023 12:41:26 -0800 Subject: [PATCH 36/53] Update munit-extensions-maven-plugin-configuration.adoc --- ...extensions-maven-plugin-configuration.adoc | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc index f0411df6..e9d69676 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc @@ -5,9 +5,9 @@ endif::[] The MUnit Extensions Maven plugin provides testing capabilities for extension development. Learn how to configure the MUnit Extensions Maven plugin to test your modules. -== Specifying Additional Argument Lines +== Specify Additional Argument Lines -Since you run the tests in a new JVM, you can specify additional argument lines to the JVM. Specify each argument in a separate `argLine`. +Because you run the tests in a new JVM, you can specify additional argument lines to the JVM. Specify each argument in a separate `argLine`. [source,xml,linenums] ---- @@ -27,7 +27,7 @@ Since you run the tests in a new JVM, you can specify additional argument lines ---- -== Enabling Runtime Discovery +== Enable Runtime Discovery Runtime discovery looks for all Mule runtime versions published on Nexus to run against your tests. @@ -58,7 +58,7 @@ From the command line, the property is `discoverRuntimes.product`. NOTE: The `product` can be CE (Community Edition), EE (Enterprise Edition), or ALL (both CE and EE). -=== Including Snapshots +=== Include Snapshots To include snapshot versions of Mule runtime, add the following line to the runtime configuration: @@ -74,7 +74,7 @@ To include snapshot versions of Mule runtime, add the following line to the runt From the command line, the property is `discoverRuntimes.includeSnapshots`. The default value is `false`. -=== Discovering Only the Latest Patches +=== Discover Only the Latest Patches To discover only the latest patch versions of Mule runtime, add the following line to the runtime configuration: @@ -90,7 +90,7 @@ To discover only the latest patch versions of Mule runtime, add the following li From the command line, the property is `discoverRuntimes.latestPatches`. The default value is `true`. -=== Discovering Since a Minimum Version +=== Discover Since a Minimum Version By default, runtime discovery searches for all Mule runtime versions since the `minMuleVersion` of the module. To change this minimum version, add the following line to the runtime configuration: @@ -106,7 +106,7 @@ By default, runtime discovery searches for all Mule runtime versions since the ` From the command line, the property is `discoverRuntimes.minMuleVersion`. The default value is the `minMuleVersion` of the module. -=== Running Against Additional Runtimes +=== Run Against Additional Runtimes By default, the MUnit Extensions Maven plugin runs against the `minMuleVersion` and the required product of the module. To specify additional runtimes to run against, add the following lines to the runtime configuration: @@ -122,7 +122,7 @@ By default, the MUnit Extensions Maven plugin runs against the `minMuleVersion` From the command line, the property is `additionalRuntimes`. -=== Skipping Runtime Discovery +=== Skip Runtime Discovery To skip runtime discovery, add the following line to the runtime configuration: @@ -138,7 +138,7 @@ To skip runtime discovery, add the following line to the runtime configuration: From the command line, the property is `discoverRuntimes.skip`. The default value is `false`. -== Using Dynamic Ports +== Use Dynamic Ports [IMPORTANT] MUnit 2.2 and later introduce the `dynamic-port` global element, that allows you to define dynamic ports at the MUnit suite level. + @@ -166,7 +166,7 @@ Dynamic Ports feature is only available as part of the MUnit Maven Plugin. + You can not expect this feature to work when running tests from inside Anypoint Studio. -- -=== Enabling Dynamic Ports +=== Enable Dynamic Ports To enable the feature, you need to add the following code to the `configuration` section of the MUnit Maven Plugin: From ca9392615f78638f724219a2cfdfaacecc1dea74 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Fri, 10 Nov 2023 12:37:03 -0800 Subject: [PATCH 37/53] editorial --- .../ROOT/pages/mtf-using-test-classes.adoc | 8 ++++---- modules/ROOT/pages/testing-oauth-modules.adoc | 19 ++++++++++--------- 2 files changed, 14 insertions(+), 13 deletions(-) diff --git a/modules/ROOT/pages/mtf-using-test-classes.adoc b/modules/ROOT/pages/mtf-using-test-classes.adoc index b81d8c0b..4ab76731 100644 --- a/modules/ROOT/pages/mtf-using-test-classes.adoc +++ b/modules/ROOT/pages/mtf-using-test-classes.adoc @@ -3,7 +3,7 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -When creating test cases, use Java classes located in `src/test/java`. Use Java classes through DataWeave or through Java Module. +When creating test cases, use Java classes located in `src/test/java` with DataWeave or Java Module. In the following example, assume that your class is located in `src/test/java/com/example/MyUtilClass.java`: @@ -19,7 +19,7 @@ public class Helper { } ---- -== Use Classes Through DataWeave +== Use Classes With DataWeave To invoke static methods using DataWeave, add the `java!` prefix to the package name of the class: @@ -35,9 +35,9 @@ To invoke static methods using DataWeave, add the `java!` prefix to the package ---- -== Use Classes Through Java Module +== Use Classes With Java Module -To use classes through Java Module: +To use classes with Java Module: . Ensure that Java Module is in your project: + diff --git a/modules/ROOT/pages/testing-oauth-modules.adoc b/modules/ROOT/pages/testing-oauth-modules.adoc index 069907a7..bb140751 100644 --- a/modules/ROOT/pages/testing-oauth-modules.adoc +++ b/modules/ROOT/pages/testing-oauth-modules.adoc @@ -5,13 +5,14 @@ endif::[] Mule runtime engine supports authorization through various OAuth grant types, including the Authorization Code grant type, which allows an external system (for example, your Mule application) to operate on behalf of a user without requiring user authentication. -However, because the Authorization Code grant type is designed to force human intervention in the authentication process that identifies users using OAuth (OAuth dance), building an automated test for an application using this grant type is challenging. +However, because the Authorization Code grant type forces human intervention in the authentication process that identifies users using OAuth (OAuth dance), building an automated test for an application using this grant type is challenging. To overcome this challenge, use the Storage Event processor to bypass the OAuth dance by manually providing a valid access token. Ensure the following requirements are met: * You must manually obtain the token. -* You must be aware that the token eventually expires. + -How often the token expires depends on the service provider to which you are connecting. +* You must be aware that the token eventually expires. ++ +How often the token expires depends on the service provider you are connecting to. * You must obtain a new token and update the test with it. == Example: OAuth-Enabled Module @@ -32,9 +33,9 @@ Consider the following configuration of Salesforce Connector using OAuth authent ---- - -<1> The application defines an object store named `tokenStore`. -<2> The application uses the `tokenStore` object store to store the OAuth token. +[calloutlist] +.. The application defines an object store named `tokenStore`. +.. The application uses the `tokenStore` object store to store the OAuth token. To use the OAuth token stored in `tokenStore` in an MUnit test, create a flow and insert your token in an MUnit Storage Event processor: @@ -72,6 +73,6 @@ After you supply the token values, your MUnit test has the following structure: ---- - -<1> Inserting the token by invoking the `storeOAuthToken` flow is the very first step in the test. -<2> The `` operation references the same config name and `resourceOwnerId` that matches the token you inserted. +[calloutlist] +.. Inserting the token by invoking the `storeOAuthToken` flow is the very first step in the test. +.. The `` operation references the same config name and `resourceOwnerId` that matches the token you inserted. From d2b9c676a17e1a7944862505595b33f0f2cdab28 Mon Sep 17 00:00:00 2001 From: sathya0 <78386709+sathya0@users.noreply.github.com> Date: Fri, 10 Nov 2023 14:22:14 -0800 Subject: [PATCH 38/53] Update modules/ROOT/pages/mtf-using-test-classes.adoc Co-authored-by: Hanna Nelson --- modules/ROOT/pages/mtf-using-test-classes.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/mtf-using-test-classes.adoc b/modules/ROOT/pages/mtf-using-test-classes.adoc index 4ab76731..3af9d821 100644 --- a/modules/ROOT/pages/mtf-using-test-classes.adoc +++ b/modules/ROOT/pages/mtf-using-test-classes.adoc @@ -35,7 +35,7 @@ To invoke static methods using DataWeave, add the `java!` prefix to the package ---- -== Use Classes With Java Module +== Use Classes with Java Module To use classes with Java Module: From 03337ffe29dce192ecb1156a9beee06d2792ef03 Mon Sep 17 00:00:00 2001 From: sathya0 <78386709+sathya0@users.noreply.github.com> Date: Fri, 10 Nov 2023 14:22:39 -0800 Subject: [PATCH 39/53] Update modules/ROOT/pages/mtf-using-test-classes.adoc Co-authored-by: Hanna Nelson --- modules/ROOT/pages/mtf-using-test-classes.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/mtf-using-test-classes.adoc b/modules/ROOT/pages/mtf-using-test-classes.adoc index 3af9d821..916eeb72 100644 --- a/modules/ROOT/pages/mtf-using-test-classes.adoc +++ b/modules/ROOT/pages/mtf-using-test-classes.adoc @@ -19,7 +19,7 @@ public class Helper { } ---- -== Use Classes With DataWeave +== Use Classes with DataWeave To invoke static methods using DataWeave, add the `java!` prefix to the package name of the class: From 4a7a44b64ddddedb61e4dd70b4ec64f3be90ee20 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Mon, 13 Nov 2023 13:26:48 -0800 Subject: [PATCH 40/53] Update munit-extensions-maven-plugin-configuration.adoc --- ...extensions-maven-plugin-configuration.adoc | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc index e9d69676..adc7d461 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc @@ -44,7 +44,7 @@ To enable runtime discovery, add the following configuration to the MUnit Extens ... - CE <1> + CE //<1> ... @@ -52,7 +52,8 @@ To enable runtime discovery, add the following configuration to the MUnit Extens ---- -<1> This enables the runtime discovery feature for all released CE runtimes. +[calloutlist] +.. This enables the runtime discovery feature for all released CE runtimes. From the command line, the property is `discoverRuntimes.product`. @@ -141,19 +142,19 @@ From the command line, the property is `discoverRuntimes.skip`. The default valu == Use Dynamic Ports [IMPORTANT] -MUnit 2.2 and later introduce the `dynamic-port` global element, that allows you to define dynamic ports at the MUnit suite level. + -Using this element instead of the plugin configuration described below allows you to set the dynamic port both from Maven and Studio. + -See xref:2.2@munit::dynamic-ports.adoc[Dynamic Ports] in MUnit to learn how to configure this element. - -When testing a Mule application in a continuous integration (CI) environment, you might encounter the following scenario: - +MUnit 2.2 and later introduces the `dynamic-port` global element, which you can use to define dynamic ports at the MUnit suite level. + +Use this element instead of the plugin configuration described below to set the dynamic port both from Maven and Studio. + +For more information about how to configure this element, refer to xref:munit::dynamic-ports.adoc[Dynamic Ports]. When testing a module in a continuous integration (CI) environment, you might encounter the following scenario: `Your test tries to open a specific port. The port is already in use. The test fails with a port binding exception.` +To solve this, use the MUnit Extensions Maven plugin that comes with a built-in feature to do just that. + + The easy solution to this problem is to have your test use a free port. -The MUnit Maven Plugin comes with a built-in feature to do just that. +The MUnit Extensions Maven plugin comes with a built-in feature to do just that. `MUnit Dynamic Ports` instructs the MUnit Maven Plugin to look for unbound ports and reserve them before running the tests over the module. Each port selected is placed in a system property under the name indicated in the configuration. The test can acquire the port number through the use of placeholders afterward. From da0fb21563398aa50bfaa9fc98c43e5fdde1a7a6 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Mon, 13 Nov 2023 17:05:06 -0800 Subject: [PATCH 41/53] Update munit-extensions-maven-plugin-configuration.adoc --- ...extensions-maven-plugin-configuration.adoc | 56 ++++++++----------- 1 file changed, 24 insertions(+), 32 deletions(-) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc index adc7d461..e0686cc4 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc @@ -150,28 +150,20 @@ When testing a module in a continuous integration (CI) environment, you might en `Your test tries to open a specific port. The port is already in use. The test fails with a port binding exception.` -To solve this, use the MUnit Extensions Maven plugin that comes with a built-in feature to do just that. +To solve this, use the dynamic ports built-in feature in the MUnit Extensions Maven plugin to have your test use a free port. Dynamic ports instruct the MUnit Extensions Maven plugin to look for unbound ports and reserves them before running the tests over the module. Each port selected is placed in a system property under the name indicated in the configuration. The test can acquire the port number through the use of placeholders afterward. - -The easy solution to this problem is to have your test use a free port. -The MUnit Extensions Maven plugin comes with a built-in feature to do just that. - -`MUnit Dynamic Ports` instructs the MUnit Maven Plugin to look for unbound ports and reserve them before running the tests over the module. Each port selected is placed in a system property under the name indicated in the configuration. -The test can acquire the port number through the use of placeholders afterward. - -TIP: The Ports to be selected by the plugin are taken from the following range: `[40000,50000)` +TIP: The ports to select by the MUnit Extensions Maven plugin are taken from the following range: `[40000,50000)`. [CAUTION] -- -Dynamic Ports feature is only available as part of the MUnit Maven Plugin. + -You can not expect this feature to work when running tests from inside Anypoint Studio. +The dynamic ports feature is available only as part of the MUnit Extensions Maven Plugin. + +You cannot expect this feature to work when running tests from inside Anypoint Studio. -- === Enable Dynamic Ports -To enable the feature, you need to add the following code to the `configuration` section of the MUnit Maven Plugin: +To enable the dynamic ports feature, add the following code to the `configuration` section of the MUnit Extensions Maven plugin: -.Dynamic Ports Configuration [source,xml,linenums] ---- @@ -189,9 +181,8 @@ To enable the feature, you need to add the following code to the `configuration` ---- -If you have the `${http.port}` placeholder in your test, the configuration looks something like: +If you have the `${http.port}` placeholder in your test, the configuration looks like this: -.Example [source,xml,linenums] ---- @@ -199,13 +190,10 @@ If you have the `${http.port}` placeholder in your test, the configuration looks ---- -== Enable surefire reports +== Disable Surefire Reports -MUnit has built-in support for Surefire. No additional configuration is needed for this but it can be disabled if not needed. +MUnit has built-in support for Surefire. No additional configuration is needed but it can be disabled if not needed. - -//_TODO: Where? Properties? pluginConfig? -.Disabling surefire reports [source,xml,linenums] ---- false @@ -213,9 +201,11 @@ MUnit has built-in support for Surefire. No additional configuration is needed f The reports can be found under `${project.build.directory}/surefire-reports`. -By default, it is set to `true`. +The default value is `true`. + +== Run Specific Tests -== To Run Specific Tests +To run specific tests, add a line for the specific test: [source,xml,linenums] ---- @@ -232,7 +222,9 @@ By default, it is set to `true`. ---- -== To Run Tests With Specific Tags +== Run Tests With Specific Tags + +To run tests with specific tags, add a line for the test with the specific tag: [source,xml,linenums] ---- @@ -249,9 +241,11 @@ By default, it is set to `true`. ---- -You can specify more than one tag by separating them using a comma. +You can specify more than one tag by separating them with a comma. + +== Skip MUnit Tests -== To Skip MUnit Tests +To skip MUnit tests, add a line to skip MUnit tests: [source,xml,linenums] ---- @@ -268,13 +262,9 @@ You can specify more than one tag by separating them using a comma. ---- +== Skip Tests After One Suite Fails -// CONFIGURATION - -== To Skip Tests After One Suite Fails - -MUnit allows you to skip the rest of the tests if one test suite fails. + -If not specified, this value is false by default. +To skip the rest of the tests if one test suite fails, add a line to skip after failure: [source,xml,linenums] ---- @@ -291,7 +281,9 @@ If not specified, this value is false by default. ---- -== To Specify the Runtime Version +The default value is `false`. + +== Specify the Runtime Version MUnit allows you to specify the runtime version in which your module being tested will run. From e66d9ac0e7b5440682833048bf4e22057f15b0bb Mon Sep 17 00:00:00 2001 From: sathya0 Date: Tue, 14 Nov 2023 09:54:08 -0800 Subject: [PATCH 42/53] Update munit-extensions-maven-plugin-configuration.adoc --- ...extensions-maven-plugin-configuration.adoc | 33 +++++++++---------- 1 file changed, 15 insertions(+), 18 deletions(-) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc index e0686cc4..f532a649 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc @@ -157,7 +157,7 @@ TIP: The ports to select by the MUnit Extensions Maven plugin are taken from the [CAUTION] -- The dynamic ports feature is available only as part of the MUnit Extensions Maven Plugin. + -You cannot expect this feature to work when running tests from inside Anypoint Studio. +You can't expect this feature to work when running tests from inside Anypoint Studio. -- === Enable Dynamic Ports @@ -283,9 +283,9 @@ To skip the rest of the tests if one test suite fails, add a line to skip after The default value is `false`. -== Specify the Runtime Version +== Specify the Mule Runtime Version -MUnit allows you to specify the runtime version in which your module being tested will run. +To specify the Mule runtime version that your tested module runs on, add a line for the Mule runtime version: [source,xml,linenums] ---- @@ -302,12 +302,13 @@ MUnit allows you to specify the runtime version in which your module being teste ---- -WARNING: If this option is set, runtime discovery and additionalRuntimes won't take effect. +WARNING: If this option is set, runtime discovery and `additionalRuntimes` don't take effect. -== To Specify The Runtime Product +== Specify The Runtime Product -MUnit allows you to specify the type of runtime in which your module being tested will run. + -The two possible values are MULE for community edition, and MULE_EE for Enterprise Edition. +You can specify the type of runtime that your tested module runs on. + +The two possible values are `MULE` for Community Edition, and `MULE_EE` for Enterprise Edition. [source,xml,linenums] ---- @@ -324,12 +325,11 @@ The two possible values are MULE for community edition, and MULE_EE for Enterpri ---- -WARNING: If this option is set, runtime discovery and additionalRuntimes won't take effect. +WARNING: If this option is set, runtime discovery and `additionalRuntimes` don't take effect. -== To Specify The JVM +== Specify The JVM -MUnit allows you to specify the jvm (or the java executable) in which your module being tested will run. -The property should be populated with the path to the executable. +You can specify the JVM (or the Java executable) that your tested module runs on. Populate the property with the path to the executable. [source,xml,linenums] ---- @@ -346,14 +346,12 @@ The property should be populated with the path to the executable. ---- -From the command line, the property is `-Dmunit.jvm` +From the command line, the property is `-Dmunit.jvm`. -== Environment Variables +== Set Environment Variables -To set additional environment variables during the test run, you can specify -them with the respective key and value. +To set additional environment variables during the test run, specify them with the respective key and value: -.Additional Environment Variables [source,xml,linenums] ---- @@ -372,8 +370,7 @@ them with the respective key and value. ---- -Environment variables can be used to replace placeholders such as `${MY_ENV}` -(using the example above). +Use environment variables to replace placeholders such as `${MY_ENV}` (from the example above). == Redirect Test Output to File From 4444b22452974f6675764940d781d3e6effeacb1 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Tue, 14 Nov 2023 10:40:14 -0800 Subject: [PATCH 43/53] Update munit-extensions-maven-plugin-configuration.adoc --- ...extensions-maven-plugin-configuration.adoc | 54 +++++++------------ 1 file changed, 19 insertions(+), 35 deletions(-) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc index f532a649..396d1a90 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc @@ -374,18 +374,12 @@ Use environment variables to replace placeholders such as `${MY_ENV}` (from the == Redirect Test Output to File -When running several tests, the build output can get very complex to read. You may want -to redirect the output of each Test suite to a file. This way what remains in the build -output will be the test results and to check the standard output of each test suite you can find it -in its respective file. +When running several tests, the build output can be complicated to read. You can redirect the build output of each test suite to a file so the build output contains the test results and the respective file contains standard output of each test suite. -These files will be located in the `testOutputDirectory` folder following this naming convention: -`munit.${suiteName}-output.txt`, where the `suiteName` represents the name of the XML file relative to the -MUnit test folder. +These files are located in the `testOutputDirectory` folder and follow the `munit.${suiteName}-output.txt` naming convention, in which `suiteName` is the name of the XML file relative to the MUnit test folder. -The test run output that doesn't belong to a particular suite won't be printed to keep the build output clean, but it can be enabled by running maven in _debug_ mode. +To keep the build output clean, the test run output that doesn't belong to a particular suite doesn't print, but you can enable it by running Maven in debug mode. -.Redirect test output to file [source,xml,linenums] ---- @@ -401,13 +395,12 @@ The test run output that doesn't belong to a particular suite won't be printed t ---- -By default, it is set to `false` +The default value is `false`. -== System Properties Variables +== Define System Properties Variables -You may wish to define specific system variables needed for your MUnit test to run successfully. The example below shows how you can send them. +You can define specific system variables needed for your MUnit test to run successfully: -.Setting system property variables [source,xml,linenums] ---- @@ -427,9 +420,9 @@ You may wish to define specific system variables needed for your MUnit test to r [TIP] ==== -Depending on the execution context, the system properties values may vary. When referencing these properties, it is a good practice to override their value to enforce test reproducibility. +Depending on the execution context, the system properties values might vary. When referencing these properties, override their value to enforce test reproducibility. -You can do so using the ­`-D` argument when running MUnit with Maven. + +You can do so by using the ­`-D` argument when running MUnit with Maven. + Variables passed with the `-D` argument take full priority over any other property. For example: @@ -439,10 +432,10 @@ For example: == Test Output Directory -You may want to choose the location where the test output files will be created. -The path specified can be absolute or written as a maven placeholder. +You can choose the location where the test output files are created. +The specified path can be an absolute path or a Maven placeholder. -.Test output directory with absolute path +.Test output directory with an absolute path [source,xml,linenums] ---- @@ -458,22 +451,21 @@ The path specified can be absolute or written as a maven placeholder. ---- -.Test output directory using maven placeholders +.Test output directory with a Maven placeholder [source,xml,linenums] ---- ${project.build.directory}/my/output/folder ---- -By default, the files will be created in `${project.build.directory}/munit-reports/output/`. +By default, the files are created in `${project.build.directory}/munit-reports/output/`. -== Shared Libraries +== Specify Shared Libraries -When requiring external libraries as explained xref:external-libs[here], you need to specify +When requiring external libraries (as explained in xref:external-libs.adoc[]), specify these libraries as `sharedLibraries` (apart from having the corresponding dependencies in the project). -For example if you defined the following annotation in your module: +For example, if you define the following external library in your module: -.External Library [source,java,linenums] ---- @ExternalLib(name = "My External Library", @@ -481,9 +473,8 @@ requiredClassName = "com.example.MyClass", coordinates = "com.example:my-external-library:1.2.3") ---- -You should configure the plugin in the following way: +You must configure the plugin in the following way: -.Shared Libraries [source,xml,linenums] ---- @@ -504,16 +495,10 @@ You should configure the plugin in the following way: ---- -== Importing External Suites and Resources - -If you want to reuse suite files across different modules and they are present in an external artifact, the plugin -allows you to include them in the run (as if they were present in the `src/test/munit` and `src/test/resources` folders). +== Import External Suites and Resources -Make sure that the dependencies are in the plugin's classpath adding them as dependencies of the plugin. +To reuse suite files that are present in an external artifact across different modules, include the suite files in the configuration as if they are present in the `src/test/munit` and `src/test/resources` folders. Ensure you add the dependencies in the plugin's classpath. -You should configure the plugin in the following way: - -.External suites and resources [source,xml,linenums] ---- @@ -544,7 +529,6 @@ You should configure the plugin in the following way: If any of the suite files or resources are not present in the classpath, the plugin fails. - == See Also * xref:munit-extensions-maven-plugin.adoc[] From 41f924817799ebcede21ac0230c8034665796e85 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Tue, 14 Nov 2023 11:00:10 -0800 Subject: [PATCH 44/53] Update munit-extensions-maven-plugin.adoc --- .../pages/munit-extensions-maven-plugin.adoc | 50 ++++++++++--------- 1 file changed, 26 insertions(+), 24 deletions(-) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin.adoc index 018e614a..c51d9b72 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin.adoc @@ -3,45 +3,50 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -This section shows you how to run your tests using the plugin. +Learn how to run your tests using the MUnit Extensions Maven plugin. -== Running MUnit Tests for a Module Project +== Run MUnit Tests for a Module Project + +To run MUnit tests for your module: [source,console] ---- mvn clean verify ---- -== Running a Specific MUnit Test Suite +== Run a Specific MUnit Test Suite -You can instruct MUnit Maven Plugin to only run tests that belong to a specific test suite by using the property `munit.test`. +You can instruct the MUnit Extensions Maven plugin to run tests that only belong to a specific test suite by using the `munit.test` property. [source,console] ---- mvn clean verify -Dmunit.test= ---- -.The property `munit.test` accepts regular expressions. The expression is applied to the name of the MUnit Test Suite file. The regular expression language is the Java implementation. This path is relative to `src/test/munit`. -The following is a valid example: +The `munit.test` property accepts regular expressions. The expression is applied to the name of the MUnit test suite file. The regular expression language is the Java implementation. This path is relative to `src/test/munit`. + +For example: + [source,console] ---- mvn clean verify -Dmunit.test=.*my-test.* ---- -You can leverage this feature by adding naming conventions to your MUnit Test suites. +You can leverage this feature by adding naming conventions to your MUnit test suites. -== To Run Specific MUnit Tests +== Run Specific MUnit Tests -In the same way that you instruct MUnit to run one test suite, you can also tell it to run a specific test inside that test suite. To do so, we again make use of the property `munit.test`, with one addition: +In the same way that you instruct MUnit to run one test suite, you can also instruct MUnit to run a specific test inside that test suite. To do so, use the `munit.test` property, with one addition: [source,console] ---- mvn clean verify -Dmunit.test=# ---- -The addition is the special character `#`. To the right of it, you should type the test name. It also accepts regular expressions. The expression is applied to the attribute `name` of the MUnit Test. +The addition is the special character `#`. After `#`, you can type the test name. It also accepts regular expressions. The expression is applied to the attribute `name` of the MUnit test. + +For example: -The following is a valid example: [source,console] ---- mvn clean verify -Dmunit.test=.*my-test.*#.*test-scenario-1.* @@ -49,10 +54,10 @@ mvn clean verify -Dmunit.test=.*my-test.*#.*test-scenario-1.* [TIP] -- -The tests inside the MUnit Test Suite that don't match the regular expression is flagged as *ignored*. +The tests inside the MUnit test suite that don't match the regular expression are flagged as *ignored*. -- -== To Run Tests Using a Specific Tag +== Run Tests Using a Specific Tag You can choose to run only the tests that you grouped under one specific tag. @@ -61,21 +66,19 @@ You can choose to run only the tests that you grouped under one specific tag. mvn clean verify -Dmunit.tags= ---- -== To Skip All Tests +== Skip All Tests -When building your module, you may want to prevent a test from running. MUnit leverages the same mechanism as Maven, so if you wish to skip tests, you can make use of the parameter `skipTests`. +When building your module, you can prevent a test from running. MUnit leverages the same mechanism as Maven, so use the `skipTests` parameter to skip tests. -.Skipping Tests example [source,console] ---- mvn clean verify -DskipTests ---- -== To Debug Tests +== Debug Tests -When testing your module, you may want to debug your code. MUnit leverages Java remote debugging, so if you wish to debug your tests you can make user of the parameter `munit.debug`. +When testing your module, you can debug your code. MUnit leverages Java remote debugging, so use the `munit.debug` parameter to debug your tests. -.Debugging Code example [source,console] ---- mvn clean verify -Dmunit.debug @@ -83,13 +86,12 @@ mvn clean verify -Dmunit.debug [TIP] -- -The default debugger will listen on port 5005. You can override the debugger JVM argument line by specifying it as the value of the property. +The default debugger listens on port 5005. You can override the debugger JVM argument line by specifying it as the value of the property: -_mvn clean verify -Dmunit.debug="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8002"_ +mvn clean verify -Dmunit.debug="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8002" -- - == See Also -* xref:2.2@munit::faq-how-to-read-munit-test-results.adoc[FAQ: How To Read MUnit Test Results] -* xref:munit-extensions-maven-plugin-configuration.adoc[MUnit Extensions Maven Plugin Configuration] +* xref:munit::munit-showing-results.adoc[] +* xref:munit-extensions-maven-plugin-configuration.adoc[] From a8516ad19354320a9730bb0444bc9878125a7ac1 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Tue, 14 Nov 2023 15:31:05 -0800 Subject: [PATCH 45/53] Update munit-extensions-maven-plugin-configuration.adoc --- .../munit-extensions-maven-plugin-configuration.adoc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc index 396d1a90..9e9742bd 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc @@ -222,7 +222,7 @@ To run specific tests, add a line for the specific test: ---- -== Run Tests With Specific Tags +== Run Tests with Specific Tags To run tests with specific tags, add a line for the test with the specific tag: @@ -304,7 +304,7 @@ To specify the Mule runtime version that your tested module runs on, add a line WARNING: If this option is set, runtime discovery and `additionalRuntimes` don't take effect. -== Specify The Runtime Product +== Specify the Runtime Product You can specify the type of runtime that your tested module runs on. @@ -327,7 +327,7 @@ The two possible values are `MULE` for Community Edition, and `MULE_EE` for Ente WARNING: If this option is set, runtime discovery and `additionalRuntimes` don't take effect. -== Specify The JVM +== Specify the JVM You can specify the JVM (or the Java executable) that your tested module runs on. Populate the property with the path to the executable. @@ -372,7 +372,7 @@ To set additional environment variables during the test run, specify them with t Use environment variables to replace placeholders such as `${MY_ENV}` (from the example above). -== Redirect Test Output to File +== Redirect Test Output to a File When running several tests, the build output can be complicated to read. You can redirect the build output of each test suite to a file so the build output contains the test results and the respective file contains standard output of each test suite. From fae173f8ff528ec42479c2bdb29e9bb4114c96ba Mon Sep 17 00:00:00 2001 From: sathya0 Date: Wed, 15 Nov 2023 09:00:53 -0800 Subject: [PATCH 46/53] editorial --- modules/ROOT/pages/connectivity-testing.adoc | 8 +++--- modules/ROOT/pages/mtf-metadata-testing.adoc | 30 ++++++++++---------- 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/modules/ROOT/pages/connectivity-testing.adoc b/modules/ROOT/pages/connectivity-testing.adoc index 71bb64d0..a868121c 100644 --- a/modules/ROOT/pages/connectivity-testing.adoc +++ b/modules/ROOT/pages/connectivity-testing.adoc @@ -7,8 +7,8 @@ Test the connectivity defined for your module. == Before You Begin -* Know how to define a connection for your module. For more information, refer to xref:connections.adoc[]. -* To create connectivity tests, add the `mtf-tools` dependency to your project: +* Understand how to define a connection for your module. For more information, refer to xref:connections.adoc[]. +* Add the `mtf-tools` dependency to your project: + [source,xml,linenums] ---- @@ -21,7 +21,7 @@ Test the connectivity defined for your module. ---- -CAUTION: Connectivity testing is available since Mule runtime engine 4.2.0. If your module has a minimum Mule version earlier than 4.2.0, add `minMuleVersion` to your connectivity testing suite, for example: ``. +CAUTION: Connectivity testing is available as of Mule runtime engine version 4.2.0. If your module has a minimum Mule version earlier than 4.2.0, add `minMuleVersion` to your connectivity testing suite, for example: ``. == Test Connectivity @@ -29,7 +29,7 @@ The `test-connectivity` processor establishes a connection using the given confi === Successful Connection -When you test that a connection is valid, you are validating that the processor does not fail. A successful connection test looks as follows: +When you test that a connection is valid, you are validating that the processor does not fail. A successful connection test appears as follows: [source,xml,linenums] ---- diff --git a/modules/ROOT/pages/mtf-metadata-testing.adoc b/modules/ROOT/pages/mtf-metadata-testing.adoc index b66d0140..e2ffa7b1 100644 --- a/modules/ROOT/pages/mtf-metadata-testing.adoc +++ b/modules/ROOT/pages/mtf-metadata-testing.adoc @@ -7,8 +7,8 @@ Test the metadata defined for your module. == Before You Begin -* Know how to define metadata in your module. For more information, refer to xref:metadata.adoc[]. -* To create metadata tests, add the `mtf-tools` dependency to your project: +* Understand how to define metadata in your module. For more information, refer to xref:metadata.adoc[]. +* Add the `mtf-tools` dependency to your project: + [source,xml,linenums] ---- @@ -21,11 +21,11 @@ Test the metadata defined for your module. ---- -CAUTION: Metadata testing is available since Mule runtime engine 4.2.0. When running your tests against an earlier version, suites containing metadata tests are ignored. +CAUTION: Metadata testing is available as of Mule runtime engine version 4.2.0. When running your tests against an earlier version, suites containing metadata tests are ignored. == Tooling Test -The `tooling-test` component validates the module's metadata at design time, unlike the `munit:test` component that validates the module's metadata at execution. The `tooling-test` component is represented as follows: +The `tooling-test` component validates the module's metadata at design time, unlike the `munit:test` component, which validates the module's metadata at execution. The following code describes the `tooling-test` component: [source,xml,linenums] ---- @@ -34,7 +34,7 @@ The `tooling-test` component validates the module's metadata at design time, unl ---- -When a suite with a tooling test runs, XML validations are disabled. When testing metadata, it might be necessary to avoid filling required parameters. +When a suite with a tooling test runs, XML validations are disabled. When testing metadata, it might be necessary to avoid entering required parameters. The tooling test can have the following parameters: @@ -43,22 +43,22 @@ The tooling test can have the following parameters: |Name |Description |`name` -| Mandatory. Defines the name of the test. The name must be unique inside the test suite. +| Required. Defines the name of the test. The name must be unique inside the test suite. |`description` -|Describes the scenario that is tested. +|Describes the scenario to test. |`ignore` -|Defines whether the test is ignored. If this parameter is not present, the test is not ignored. +|Specifies whether to ignore the test. If this parameter is not present, the test is not ignored. |`tags` -|Comma-separated list of tags to assign to the test. +|Specifies a comma-separated list of tags to assign to the test. |`expectFailureCode` -|Defines the failure code that is received after the metadata calculation of this test. +|Defines the failure code that is received after calculating the metadata for this test. |`expectFailureMessage` -|Defines the failure message that is received after the metadata calculation of this test. +|Defines the failure message that is received after calculating the metadata for this test. |=== @@ -79,7 +79,7 @@ Contains all the validations regarding the result of the metadata scope. == Metadata Scopes -Use metadata scopes in the tooling test. You can use only one metadata scope in each test. You can use either an operation or a source in each of these scopes. +Use metadata scopes in the tooling test. You can use only one metadata scope in each test and you can use either an operation or a source in each metadata scope. === Metadata Keys @@ -115,7 +115,7 @@ The `input metadata` scope obtains the metadata type for the specified parameter === Output Metadata -The `output metadata` obtains the metadata type for the output `payload` of the module. The `payload` contains a JSON representation of the metadata type: +The `output metadata` scope obtains the metadata type for the output `payload` of the module, which contains a JSON representation of the metadata type: [source,xml,linenums] ---- @@ -186,7 +186,7 @@ A common use case when testing metadata is validating failures that might occur Use the assert type processor to assert the metadata type structure returned by metadata scopes such as `get-input-metadata`, `get-output-metadata`, and `get-attributes-metadata`. -The assert type processor compares the structure of both metadata types and ignores fields such as `format` or `annotations`. To perform assertions over these fields, you can use the `payload` result of the metadata scopes operations as shown in the previous examples. +The assert type processor compares the structure of both metadata types and ignores fields such as `format` or `annotations`. To perform assertions over these fields, use the `payload` result of the metadata scopes operations as shown in the previous examples. If the assertion fails, the processor throws a `java.lang.AssertionError` error. @@ -217,7 +217,7 @@ The `actual` field defaults to `payload`. You can choose to not specify the `act To compare a metadata type structure with another metadata type structure obtained from a schema, use the `fromSchema` parameter. -The `fromSchema` parameter supports metadata types such as JSON schema, XSD schema, and RAML data types. The file extensions must be `.json`, `.xsd`, and `.raml` respectively and must be stored in the `src/test/resources` folder. +The `fromSchema` parameter supports metadata types, such as JSON schema, XSD schema, and RAML data types. The file extensions must be `.json`, `.xsd`, and `.raml` respectively, and must be stored in the `src/test/resources` folder. [source,xml,linenums] ---- From 88bb4e2386965be8c2290682ebdb2ddf29aeabe2 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Fri, 17 Nov 2023 10:01:22 -0800 Subject: [PATCH 47/53] Update testing-writing-your-first-munit-test.adoc --- .../ROOT/pages/testing-writing-your-first-munit-test.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc index 00d34a44..31e5b3d8 100644 --- a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc +++ b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc @@ -28,9 +28,9 @@ To configure your module to run your MUnit tests, you must configure your `pom.x src/test/munit ${basedir}/target/test-mule/munit - 1.0.0 - 2.2.3 - 3.0.2 + 1.1.3 + 2.3.0 + 3.1.0 ... ... From 719a3e640b24a70d302312d5d3b9b6ec868d2322 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Fri, 17 Nov 2023 11:45:16 -0800 Subject: [PATCH 48/53] Update testing-writing-your-first-munit-test.adoc --- modules/ROOT/pages/testing-writing-your-first-munit-test.adoc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc index 31e5b3d8..601bf362 100644 --- a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc +++ b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc @@ -36,6 +36,9 @@ To configure your module to run your MUnit tests, you must configure your `pom.x ... ---- ++ +NOTE: Starting from version 1.x, this configuration might already be set up given a minMuleVersion parent. ++ . Add the Maven Resources Plugin: + [source,xml,linenums] From 7b093eb8bdb58e451baed39dbd16e3b0d75c3850 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Mon, 27 Nov 2023 11:54:15 -0800 Subject: [PATCH 49/53] editorial --- ...extensions-maven-plugin-configuration.adoc | 93 ++++++++----------- .../pages/munit-extensions-maven-plugin.adoc | 27 +++--- 2 files changed, 52 insertions(+), 68 deletions(-) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc index 9e9742bd..96764193 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc @@ -44,7 +44,7 @@ To enable runtime discovery, add the following configuration to the MUnit Extens ... - CE //<1> + `Product` //<1> ... @@ -52,16 +52,14 @@ To enable runtime discovery, add the following configuration to the MUnit Extens ---- -[calloutlist] -.. This enables the runtime discovery feature for all released CE runtimes. -From the command line, the property is `discoverRuntimes.product`. +The `Product` can be CE (Community Edition), EE (Enterprise Edition), or ALL (both CE and EE). For example, if the `Product` is CE, the runtime discovery feature is enabled for all released CE runtimes. -NOTE: The `product` can be CE (Community Edition), EE (Enterprise Edition), or ALL (both CE and EE). +From the command line, use the `discoverRuntimes.product` property to enable runtime discovery. === Include Snapshots -To include snapshot versions of Mule runtime, add the following line to the runtime configuration: +To include snapshot versions of Mule runtime, add an `includeSnapshots` property to the runtime configuration: [source,xml,linenums] ---- @@ -73,11 +71,11 @@ To include snapshot versions of Mule runtime, add the following line to the runt ---- -From the command line, the property is `discoverRuntimes.includeSnapshots`. The default value is `false`. +From the command line, use the `discoverRuntimes.includeSnapshots` property to include snapshots. The default value is `false`. === Discover Only the Latest Patches -To discover only the latest patch versions of Mule runtime, add the following line to the runtime configuration: +To discover only the latest patch versions of Mule runtime, add a `latestPatches` property to the runtime configuration: [source,xml,linenums] ---- @@ -89,11 +87,11 @@ To discover only the latest patch versions of Mule runtime, add the following li ---- -From the command line, the property is `discoverRuntimes.latestPatches`. The default value is `true`. +From the command line, use the `discoverRuntimes.latestPatches` property to discover only the latest patches. The default value is `true`. === Discover Since a Minimum Version -By default, runtime discovery searches for all Mule runtime versions since the `minMuleVersion` of the module. To change this minimum version, add the following line to the runtime configuration: +By default, runtime discovery searches for all Mule runtime versions since the `minMuleVersion` of the module. To change the minimum version, add a `minMuleVersion` property to the runtime configuration: [source,xml,linenums] ---- @@ -105,11 +103,11 @@ By default, runtime discovery searches for all Mule runtime versions since the ` ---- -From the command line, the property is `discoverRuntimes.minMuleVersion`. The default value is the `minMuleVersion` of the module. +From the command line, use the `discoverRuntimes.minMuleVersion` property to discover runtimes since a minimum version. The default value is the `minMuleVersion` of the module. === Run Against Additional Runtimes -By default, the MUnit Extensions Maven plugin runs against the `minMuleVersion` and the required product of the module. To specify additional runtimes to run against, add the following lines to the runtime configuration: +By default, the MUnit Extensions Maven plugin runs against the `minMuleVersion` and the required product of the module. To specify additional runtimes to run against, add `additionalRuntime` properties to the runtime configuration: [source,xml,linenums] ---- @@ -121,11 +119,11 @@ By default, the MUnit Extensions Maven plugin runs against the `minMuleVersion` ---- -From the command line, the property is `additionalRuntimes`. +From the command line, use the `additionalRuntimes` property to run against additional runtimes. === Skip Runtime Discovery -To skip runtime discovery, add the following line to the runtime configuration: +To skip runtime discovery, add a `skip` property to the runtime configuration: [source,xml,linenums] ---- @@ -137,28 +135,24 @@ To skip runtime discovery, add the following line to the runtime configuration: ---- -From the command line, the property is `discoverRuntimes.skip`. The default value is `false`. +From the command line, use the `discoverRuntimes.skip` property to skip runtime discovery. The default value is `false`. == Use Dynamic Ports [IMPORTANT] MUnit 2.2 and later introduces the `dynamic-port` global element, which you can use to define dynamic ports at the MUnit suite level. + -Use this element instead of the plugin configuration described below to set the dynamic port both from Maven and Studio. + +Use this element instead of the plugin configuration described below to set the dynamic port from both Maven and Studio. + For more information about how to configure this element, refer to xref:munit::dynamic-ports.adoc[Dynamic Ports]. When testing a module in a continuous integration (CI) environment, you might encounter the following scenario: `Your test tries to open a specific port. The port is already in use. The test fails with a port binding exception.` -To solve this, use the dynamic ports built-in feature in the MUnit Extensions Maven plugin to have your test use a free port. Dynamic ports instruct the MUnit Extensions Maven plugin to look for unbound ports and reserves them before running the tests over the module. Each port selected is placed in a system property under the name indicated in the configuration. The test can acquire the port number through the use of placeholders afterward. +To solve this, use the dynamic ports built-in feature in the MUnit Extensions Maven plugin to have your test use a free port. Dynamic ports instruct the MUnit Extensions Maven plugin to look for unbound ports and reserves them before running the tests over the module. Each selected port is placed in a system property under the name indicated in the configuration. The test can acquire the port number through the use of placeholders afterward. -TIP: The ports to select by the MUnit Extensions Maven plugin are taken from the following range: `[40000,50000)`. +The ports that the MUnit Extensions Maven plugin can select are in the following range: `[40000,50000)`. -[CAUTION] --- -The dynamic ports feature is available only as part of the MUnit Extensions Maven Plugin. + -You can't expect this feature to work when running tests from inside Anypoint Studio. --- +The dynamic ports feature is available only as part of the MUnit Extensions Maven plugin. This feature doesn't work when running tests from inside Anypoint Studio. === Enable Dynamic Ports @@ -192,20 +186,20 @@ If you have the `${http.port}` placeholder in your test, the configuration looks == Disable Surefire Reports -MUnit has built-in support for Surefire. No additional configuration is needed but it can be disabled if not needed. +MUnit has built-in support for Surefire. You can disable this support if it's not needed. [source,xml,linenums] ---- false ---- -The reports can be found under `${project.build.directory}/surefire-reports`. +The reports are located under `${project.build.directory}/surefire-reports`. The default value is `true`. == Run Specific Tests -To run specific tests, add a line for the specific test: +To run a specific test, add an `munitTest` property for each specific test to the configuration section of the MUnit Extensions Maven plugin: [source,xml,linenums] ---- @@ -224,7 +218,7 @@ To run specific tests, add a line for the specific test: == Run Tests with Specific Tags -To run tests with specific tags, add a line for the test with the specific tag: +To run tests with specific tags, add an `munitTags` property for the test with the specific tag to the configuration section of the MUnit Extensions Maven plugin. Separate the tags with commas: [source,xml,linenums] ---- @@ -234,18 +228,16 @@ To run tests with specific tags, add a line for the test with the specific tag: munit-extensions-maven-plugin ... - exampleMunitTag + exampleMunitTag,exampleMunitTag2 ... ---- -You can specify more than one tag by separating them with a comma. - == Skip MUnit Tests -To skip MUnit tests, add a line to skip MUnit tests: +To skip MUnit tests, add a `skipMunitTests` property to skip MUnit tests to the configuration section of the MUnit Extensions Maven plugin: [source,xml,linenums] ---- @@ -264,7 +256,7 @@ To skip MUnit tests, add a line to skip MUnit tests: == Skip Tests After One Suite Fails -To skip the rest of the tests if one test suite fails, add a line to skip after failure: +To skip the rest of the tests if one test suite fails, add a `skipAfterFailure` property to skip after failure to the configuration section of the MUnit Extensions Maven plugin: [source,xml,linenums] ---- @@ -285,7 +277,7 @@ The default value is `false`. == Specify the Mule Runtime Version -To specify the Mule runtime version that your tested module runs on, add a line for the Mule runtime version: +To specify the Mule runtime version that your tested module runs on, add a `runtimeVersion` property for the Mule runtime version to the configuration section of the MUnit Extensions Maven plugin: [source,xml,linenums] ---- @@ -302,13 +294,13 @@ To specify the Mule runtime version that your tested module runs on, add a line ---- -WARNING: If this option is set, runtime discovery and `additionalRuntimes` don't take effect. +If this option is set, runtime discovery and `additionalRuntimes` don't take effect. == Specify the Runtime Product You can specify the type of runtime that your tested module runs on. -The two possible values are `MULE` for Community Edition, and `MULE_EE` for Enterprise Edition. +Values are `MULE` for Community Edition, and `MULE_EE` for Enterprise Edition. [source,xml,linenums] ---- @@ -325,11 +317,11 @@ The two possible values are `MULE` for Community Edition, and `MULE_EE` for Ente ---- -WARNING: If this option is set, runtime discovery and `additionalRuntimes` don't take effect. +If this option is set, runtime discovery and `additionalRuntimes` don't take effect. == Specify the JVM -You can specify the JVM (or the Java executable) that your tested module runs on. Populate the property with the path to the executable. +To specify the JVM (Java executable) that your tested module runs on, populate the `jvm` property with the path to the executable: [source,xml,linenums] ---- @@ -346,7 +338,7 @@ You can specify the JVM (or the Java executable) that your tested module runs on ---- -From the command line, the property is `-Dmunit.jvm`. +From the command line, use the `-Dmunit.jvm` property to specify the JVM. == Set Environment Variables @@ -370,11 +362,11 @@ To set additional environment variables during the test run, specify them with t ---- -Use environment variables to replace placeholders such as `${MY_ENV}` (from the example above). +Use environment variables to replace `${MY_ENV}` and `${MY_OTHER_ENV}`. == Redirect Test Output to a File -When running several tests, the build output can be complicated to read. You can redirect the build output of each test suite to a file so the build output contains the test results and the respective file contains standard output of each test suite. +When running several tests, the build output can be complicated to read. You can redirect the build output of each test suite to a file so that the build output contains the test results and the respective file contains the standard output of each test suite. These files are located in the `testOutputDirectory` folder and follow the `munit.${suiteName}-output.txt` naming convention, in which `suiteName` is the name of the XML file relative to the MUnit test folder. @@ -418,24 +410,18 @@ You can define specific system variables needed for your MUnit test to run succe ---- -[TIP] -==== Depending on the execution context, the system properties values might vary. When referencing these properties, override their value to enforce test reproducibility. You can do so by using the ­`-D` argument when running MUnit with Maven. + -Variables passed with the `-D` argument take full priority over any other property. - -For example: - -`-Dmy.property.key=my.property.another.value` -==== +Variables passed with the `-D` argument take full priority over any other property, for example, `-Dmy.property.key=my.property.another.value`. == Test Output Directory You can choose the location where the test output files are created. The specified path can be an absolute path or a Maven placeholder. -.Test output directory with an absolute path +If the specified path is an absolute path, the test output directory looks like this: + [source,xml,linenums] ---- @@ -451,7 +437,8 @@ The specified path can be an absolute path or a Maven placeholder. ---- -.Test output directory with a Maven placeholder +If the specified path is a Maven placeholder, the test output directory looks like this: + [source,xml,linenums] ---- ${project.build.directory}/my/output/folder @@ -462,7 +449,7 @@ By default, the files are created in `${project.build.directory}/munit-reports/o == Specify Shared Libraries When requiring external libraries (as explained in xref:external-libs.adoc[]), specify -these libraries as `sharedLibraries` (apart from having the corresponding dependencies in the project). +these libraries as `sharedLibraries`. You must also have the corresponding dependencies in the project. For example, if you define the following external library in your module: @@ -497,7 +484,7 @@ You must configure the plugin in the following way: == Import External Suites and Resources -To reuse suite files that are present in an external artifact across different modules, include the suite files in the configuration as if they are present in the `src/test/munit` and `src/test/resources` folders. Ensure you add the dependencies in the plugin's classpath. +To reuse suite files that are present in an external artifact across different modules, include the suite files in the configuration as if they are present in the `src/test/munit` and `src/test/resources` folders. Ensure that you add the dependencies in the plugin's classpath. [source,xml,linenums] ---- @@ -527,7 +514,7 @@ To reuse suite files that are present in an external artifact across different m ---- -If any of the suite files or resources are not present in the classpath, the plugin fails. +If any of the suite files or resources aren't present in the classpath, the plugin fails. == See Also diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin.adoc index c51d9b72..e7d378f3 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin.adoc @@ -3,7 +3,7 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -Learn how to run your tests using the MUnit Extensions Maven plugin. +Learn how to run your tests by using the MUnit Extensions Maven plugin. == Run MUnit Tests for a Module Project @@ -16,14 +16,14 @@ mvn clean verify == Run a Specific MUnit Test Suite -You can instruct the MUnit Extensions Maven plugin to run tests that only belong to a specific test suite by using the `munit.test` property. +You can instruct the MUnit Extensions Maven plugin to run tests that belong only to a specific test suite by using the `munit.test` property: [source,console] ---- mvn clean verify -Dmunit.test= ---- -The `munit.test` property accepts regular expressions. The expression is applied to the name of the MUnit test suite file. The regular expression language is the Java implementation. This path is relative to `src/test/munit`. +The `munit.test` property accepts regular, Java expressions applied to the name of the MUnit test suite file. The path is relative to `src/test/munit`. For example: @@ -36,14 +36,14 @@ You can leverage this feature by adding naming conventions to your MUnit test su == Run Specific MUnit Tests -In the same way that you instruct MUnit to run one test suite, you can also instruct MUnit to run a specific test inside that test suite. To do so, use the `munit.test` property, with one addition: +In the same way that you instruct MUnit to run one test suite, you can also instruct MUnit to run a specific test inside that test suite. To do so, use the `munit.test` property, followed by `#` and the test name: [source,console] ---- mvn clean verify -Dmunit.test=# ---- -The addition is the special character `#`. After `#`, you can type the test name. It also accepts regular expressions. The expression is applied to the attribute `name` of the MUnit test. +The test also accepts regular expressions applied to the `name` attribute: For example: @@ -52,14 +52,11 @@ For example: mvn clean verify -Dmunit.test=.*my-test.*#.*test-scenario-1.* ---- -[TIP] --- -The tests inside the MUnit test suite that don't match the regular expression are flagged as *ignored*. --- +The MUnit Extensions Maven plugin flags tests inside the MUnit test suite as *ignored* if they don't match the regular expression. == Run Tests Using a Specific Tag -You can choose to run only the tests that you grouped under one specific tag. +You can choose to run only the tests that you grouped under one specific tag: [source,console] ---- @@ -68,7 +65,7 @@ mvn clean verify -Dmunit.tags= == Skip All Tests -When building your module, you can prevent a test from running. MUnit leverages the same mechanism as Maven, so use the `skipTests` parameter to skip tests. +When building your module, you can prevent a test from running by using the `skipTests` parameter: [source,console] ---- @@ -77,19 +74,19 @@ mvn clean verify -DskipTests == Debug Tests -When testing your module, you can debug your code. MUnit leverages Java remote debugging, so use the `munit.debug` parameter to debug your tests. +When testing your module, you can debug your code. MUnit leverages Java remote debugging, so use the `munit.debug` parameter to debug your tests: [source,console] ---- mvn clean verify -Dmunit.debug ---- -[TIP] --- The default debugger listens on port 5005. You can override the debugger JVM argument line by specifying it as the value of the property: +[source,console] +---- mvn clean verify -Dmunit.debug="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8002" --- +---- == See Also From 8a42181acabc0daa6ea1cb69e81779cd60f1f8a6 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Wed, 29 Nov 2023 09:01:31 -0800 Subject: [PATCH 50/53] editorial --- .../pages/munit-extensions-maven-plugin-configuration.adoc | 6 +++--- modules/ROOT/pages/munit-extensions-maven-plugin.adoc | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc index 96764193..67661fba 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin-configuration.adoc @@ -218,7 +218,7 @@ To run a specific test, add an `munitTest` property for each specific test to th == Run Tests with Specific Tags -To run tests with specific tags, add an `munitTags` property for the test with the specific tag to the configuration section of the MUnit Extensions Maven plugin. Separate the tags with commas: +To run tests with specific tags, add an `munitTags` property for the tests with the specific tags to the configuration section of the MUnit Extensions Maven plugin. Separate the tags with commas, for example: [source,xml,linenums] ---- @@ -228,7 +228,7 @@ To run tests with specific tags, add an `munitTags` property for the test with t munit-extensions-maven-plugin ... - exampleMunitTag,exampleMunitTag2 + exampleMUnitTag,exampleMUnitTag2 ... @@ -256,7 +256,7 @@ To skip MUnit tests, add a `skipMunitTests` property to skip MUnit tests to the == Skip Tests After One Suite Fails -To skip the rest of the tests if one test suite fails, add a `skipAfterFailure` property to skip after failure to the configuration section of the MUnit Extensions Maven plugin: +To skip the rest of the tests if one test suite fails, add a `skipAfterFailure` property to the configuration section of the MUnit Extensions Maven plugin: [source,xml,linenums] ---- diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin.adoc index e7d378f3..af7fd363 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin.adoc @@ -23,7 +23,7 @@ You can instruct the MUnit Extensions Maven plugin to run tests that belong only mvn clean verify -Dmunit.test= ---- -The `munit.test` property accepts regular, Java expressions applied to the name of the MUnit test suite file. The path is relative to `src/test/munit`. +The `munit.test` property accepts regular Java expressions applied to the name of the MUnit test suite file. The path is relative to `src/test/munit`. For example: From 2cbe5d0bddc8242b871aad2074cb704bb98fbe9c Mon Sep 17 00:00:00 2001 From: sathya0 Date: Wed, 29 Nov 2023 09:48:12 -0800 Subject: [PATCH 51/53] Update munit-extensions-maven-plugin.adoc --- modules/ROOT/pages/munit-extensions-maven-plugin.adoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin.adoc index af7fd363..ec09e1d9 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin.adoc @@ -63,6 +63,8 @@ You can choose to run only the tests that you grouped under one specific tag: mvn clean verify -Dmunit.tags= ---- +For more information about how to tag your tests, refer to xref:munit::munit-test-concept.adoc#test-tag-attribute[]. + == Skip All Tests When building your module, you can prevent a test from running by using the `skipTests` parameter: From bcc2b1e114a0bf7808139318e1f16023b71c99ba Mon Sep 17 00:00:00 2001 From: sathya0 Date: Wed, 29 Nov 2023 13:25:43 -0800 Subject: [PATCH 52/53] Update munit-extensions-maven-plugin.adoc --- modules/ROOT/pages/munit-extensions-maven-plugin.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/munit-extensions-maven-plugin.adoc b/modules/ROOT/pages/munit-extensions-maven-plugin.adoc index ec09e1d9..d54e0086 100644 --- a/modules/ROOT/pages/munit-extensions-maven-plugin.adoc +++ b/modules/ROOT/pages/munit-extensions-maven-plugin.adoc @@ -63,7 +63,7 @@ You can choose to run only the tests that you grouped under one specific tag: mvn clean verify -Dmunit.tags= ---- -For more information about how to tag your tests, refer to xref:munit::munit-test-concept.adoc#test-tag-attribute[]. +For more information about how to tag your tests, refer to xref:munit::munit-test-concept.adoc#test-tag-attribute[Test Tag Attribute]. == Skip All Tests From f0442dfe0b402ffc44e7330e06853e46812076a7 Mon Sep 17 00:00:00 2001 From: sathya0 Date: Mon, 4 Dec 2023 08:56:43 -0800 Subject: [PATCH 53/53] tech review --- modules/ROOT/pages/connectivity-testing.adoc | 4 +--- modules/ROOT/pages/mtf-metadata-testing.adoc | 4 +--- modules/ROOT/pages/testing-writing-your-first-munit-test.adoc | 4 ++-- 3 files changed, 4 insertions(+), 8 deletions(-) diff --git a/modules/ROOT/pages/connectivity-testing.adoc b/modules/ROOT/pages/connectivity-testing.adoc index a868121c..a5841d62 100644 --- a/modules/ROOT/pages/connectivity-testing.adoc +++ b/modules/ROOT/pages/connectivity-testing.adoc @@ -15,14 +15,12 @@ Test the connectivity defined for your module. com.mulesoft.munit mtf-tools - 1.0.0 + 1.2.0 mule-plugin test ---- -CAUTION: Connectivity testing is available as of Mule runtime engine version 4.2.0. If your module has a minimum Mule version earlier than 4.2.0, add `minMuleVersion` to your connectivity testing suite, for example: ``. - == Test Connectivity The `test-connectivity` processor establishes a connection using the given configuration. If testing connectivity with the given configuration fails, the processor fails with the proper exception, description, and error type (if present). diff --git a/modules/ROOT/pages/mtf-metadata-testing.adoc b/modules/ROOT/pages/mtf-metadata-testing.adoc index e2ffa7b1..067848c5 100644 --- a/modules/ROOT/pages/mtf-metadata-testing.adoc +++ b/modules/ROOT/pages/mtf-metadata-testing.adoc @@ -15,14 +15,12 @@ Test the metadata defined for your module. com.mulesoft.munit mtf-tools - 1.0.0 + 1.2.0 mule-plugin test ---- -CAUTION: Metadata testing is available as of Mule runtime engine version 4.2.0. When running your tests against an earlier version, suites containing metadata tests are ignored. - == Tooling Test The `tooling-test` component validates the module's metadata at design time, unlike the `munit:test` component, which validates the module's metadata at execution. The following code describes the `tooling-test` component: diff --git a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc index 601bf362..ba4e2a43 100644 --- a/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc +++ b/modules/ROOT/pages/testing-writing-your-first-munit-test.adoc @@ -28,8 +28,8 @@ To configure your module to run your MUnit tests, you must configure your `pom.x src/test/munit ${basedir}/target/test-mule/munit - 1.1.3 - 2.3.0 + 1.2.0 + 3.1.0 3.1.0 ...