Giter Site home page Giter Site logo

citric's Introduction

Welcome Dear Visitor!

I create plugins for JetBrains products based on the IntelliJ Platform. I have more than a decade experience in QA and test automation, so my main focus is on test automation related libraries.

Beside the current projects I maintain, I also offer IDE plugin development and consultation services. If you are interested, you can contact me via one of the ways below.

I also do Hungarian translations of software and other technical materials. More details here.

On JetBrains Marketplace:

On npm:

Other:

Places you can find me at: Website / LinkedIn / X / I(J)nspector blog / JetBrains Platform Slack / E-mail: pmplugindev at protonmail dot com

citric's People

Contributors

picimako avatar

Watchers

avatar

citric's Issues

JSON/YAML schema for YAML based Citrus test source files

Summary

Citrus provides various DSLs besides Java to write tests, and one among them is YAML files.

Tasks

  • Implement a custom JSON schema provider for Citrus YAML test source files.
  • Such YAML files have to be recognized. That will be done based on the values specified in the citrus.yaml.file.name.pattern property of the citrus-application.properties.
    • If #17 is completed beforehand, custom configuration files must also be taken into account.
    • If the citrus.yaml.file.name.pattern property is not specified or is blank, then it will fall back to the Citrus defaults.
    • The file name patterns must be cached/indexed, and updated when the Citrus configuration file changes.
    • File name patterns that would match files with not .yml or .yaml extension should be excluded.
    • Optionally, for cases when the file name patterns are specified externally via the corresponding system property or environment variable, an option on the plugin settings UI could be introduced, so that users could customize/extend the list of YAML files to be recognized.
  • Schemas must be Citrus-version specific, so that the proper schemas could be provided for different Citrus versions.

Questions

Resources

Handle separate IntelliJ JSON plugin when adding support for 2024.3

Summary

IntelliJ 2024.3 will use a separate JSON plugin instead of the currently bundled one, thus when adding support for that major version, make sure that JSON specific features will be usable.

Tasks

  • From the Marketplace notification: Please declare an explicit dependency on com.intellij.modules.json to ensure compatibility with version 2024.3

Question

  • A separate plugin release might need to be released: so one would support IDEs up to 2024.2, the other would support them 2024.3 and up.

Add Run/Debug actions for Citrus Groovy files

Summary

Run and Debug actions (via line markers and the Project View context menu) are available for YAML files. This issue is to cover the Groovy DSL.

Tasks

  • Extend the current run line marker to recognize Citrus Groovy test files as well, including
    • the line marker
    • project view context menu
  • This issue focuses only on the Gradle runner part, and does not include execution via Maven.

SQL action support

Summary

Add SQL support for Citrus.

Tasks

* Some may not be doable.

Java/Groovy XML Spring XML YAML
SQL language injection sql().statement() test.actions.sql.statements.statement testcase.actions.sql.statement actions.sql.statements.statement
Citrus source file line marker sql().sqlResource() test.actions.sql.statements@file testcase.actions.sql.resource@file actions.sql.statements.file
Highlight column names in statements and 'validate'/'extract' that are specified in 'validate'/'extract' sql().query().statement()
sql().query().validate()		 test.actions.sql.statements.statement
test.actions.sql.validate@column		 test.actions.sql.statement
test.actions.sql.validate@column		 actions.sql.statements.statement
actions.sql.validate.column
Code folding for 'validate'/'extract <validate column="ID" value="1"/>
<validate ID == 1/> 		<validate column="ID" value="1"/>
<validate ID == 1/> 		validate: - column: "ID" value: "1"
validate: - ID == 1
Code completion of column names in 'validate'/'extract' that are known in 'statement' $(sql().dataSource(dataSource).query().statement("select NAME from CUSTOMERS where CUSTOMER_ID='${customerId}'").validate("[caret]", "")
At caret: NAME
Bean completion (DataSource) sql().dataSource() test.actions.sql@datasource testcase.actions.sql@datasource actions.sql.datasource
Bean completion (TransactionManager) sql().transactionManager() test.actions.sql.transaction.manager testcase.actions.sql.transaction-manager actions.sql.transaction.manager
Groovy language injection with additional prefix code sql().validateScript() sql.validate.scrip sql.validate-script sql.validate.script.value
  • If possible, an intention action that with which the user could execute the SQL statement in a data source configured in the Database tool window.
    • It is a question whether the tool window can execute SQL statements from e.g. the clipboard, and not from an .sql file.
    • It is also a question if and how configured datasources can be queried, and if there is an option to target the execution from a plugin.
    • The intention action would need to exclude statements that contain Citrus variable references, Citrus functions or validation matchers, or other dynamic data.

Resources

Line marker for class path resource references

Summary

There is Java methods that accept resource paths, including paths of classpath resources. To make the navigation to those resources quicker, line markers could be added.

Tasks

  • Implement line markers for methods that accept classpath resource paths.
    • File resource paths are out of scope.
  • The line marker would display the icon of the referenced resource file.
  • The line marker with a single click would open the resource in the editor.
  • Paths are treated as classpath resources when either they have no prefix, or the prefix is classpath:.
  • Since classpath resources are absolute, the logic will be to locate the src/test/resources folder of the current Java file's module, and locate the resource relative to that.

TBD

  • The exact methods and arguments to support this are to be collected.

Code folding in the XML DSLs

Summary

Due to the nature of XML, such files can be noisy and unnecessarily long, so some code folding could help this case and lessen the cognitive load and comprehension of Citrus XML test files.

One simple example would be the echo action. The code folding could turn

<echo>
  <message>Some message to print</message>
</echo>

into

<echo>Some message to print</echo>

and hide the <message> tags.

Tasks

  • Collect the tags that could be folded.
  • Implement code folding. It might be something similar that goes on in the Just Kitting plugin.

Folding candidates

  • echo in XML and Spring XML
<echo>
  <message>Some message to print</message>
</echo>

<echo>Some message to print</echo>
  • load properties in XML and Spring XML
<load>
  <properties file="classpath:some/file" />
</load>

<load properties: classpath:some/file />
  • receive.message.builder with @file in Spring
<receive endpoint="myMessageEndpoint">
    <message>
        <builder type="groovy" file="classpath:org/citrusframework/actions/payload.groovy"/>
    </message>
</receive>

<receive message "classpath:org/citrusframework/actions/payload.groovy" at "myMessageEndpoint" />
  • send.message.builder with @file in Spring
<send endpoint="myMessageEndpoint">
    <message>
        <builder type="groovy" file="classpath:org/citrusframework/actions/payload.groovy" />
    </message>
</send>

<send message "classpath:org/citrusframework/actions/payload.groovy" to "myMessageEndpoint" />
  • receive.message.validate.script with @file in Spring
<message>
    <validate>
        <script type="groovy"
                file="classpath:org/citrusframework/jms/integration/helloValidationScript.groovy"/>
    </validate>
</message>

<validate by groovy script "classpath:org/citrusframework/jms/integration/helloValidationScript.groovy" />
  • receive.validate.script with @file in non-Spring
<validate>
  <script type="groovy" file="classpath:some/file" />
</validate>

<validate by groovy script "classpath:some/file" />
<jms:purge-jms-queues>
    <jms:queue ref="myQueue"/>
    <jms:queue name="JMS.Queue.1"/>
</jms:purge-jms-queues>

<jms:purge-jms-queues ref:myQueue, name:JMS.Queue.1 />
or
<jms:purge-jms-queues myQueue, "JMS.Queue.1" />
  • Camel remove/start/stop routes at
    • remove-routes.route
    • start-routes.route
    • stop-routes.route tag in Spring
<camel:remove-routes camel-context="camelContext">
  <route id="route_1"/>
  <route id="route_2"/>
  <route id="route_3"/>
</camel:remove-routes>

<camel:remove-routes in "camelContext": "route_1", "route_2", "route_3" />

Code completion for validation matchers

Summary

In a similar fashion to #14 , validation matchers could also be code completed.

Tasks

  • Implement code completion to suggest the list of available Citrus validation matchers.
  • The completion would be invoked in string literals where the caret is placed inside two @ symbols.
  • For now, it would work only in the Java DSL.

Resources

Easy navigation from @CitrusTestSource method to test resource

Summary

@CitrusTestSource annotated methods reference test scripts and test descriptor files in other DSLs. To make the lookup and navigation to those files simpler and quicker, some kind of navigation option should be implemented.

Tasks

  • The first option is a line marker, but considering that there can be multiple files and locations specified and in multiple ways, there may need to be a distinction, and separate options to navigate to them separately.
  • The sources attribute will support only classpath resource paths, for now.

Combination of options

  • File extensions
    • XML, SPRING: .xml
    • YAML: .yaml
    • GROOVY: .groovy
name packageName packageScan sources Executed
Java test method name in package of the declaring class.
+ name attribute value + file extension of type in package of the declaring class.
+ Java test method name in the packageName package.
+ The Java test method name is ignored. Test names are the ones found in the packageScan package.
+ The files specified in sources in the packages of files specified in sources
+ + name attribute value + file extension of type in packageName package.
+ + name attribute value + file extension of type from the current package, AND all tests in the packageScan package.
+ + Only the files specified in sources, but a GroovyTestLoader is also created for name which is not executed.
+ + Only the files found in packageScan.
+ + + name attribute value + file extension of type from the packageName package, AND all tests in the packageScan package.
+ + Only the files specified in sources.
+ + + Only the files specified in sources, but a GroovyTestLoader is also created for name which is not executed.
+ + Files found in packageScan, AND in source.
+ + + Only the name attribute value + file extension of type from the current package but GroovyTestLoaders are also created for packageScan and sources that are not executed.
+ + + Only the files specified in packageScan and sources.
+ + + + name attribute value + file extension of type from the packageName package, AND sources, but GroovyTestLoaders are also created for packageScan which are not executed.

Support file: and jar: resources when detecting test source files and methods

Summary

Currently, only classpath resources are supported when dealing with @CitrusTestSource test methods, either in case of looking up test source files based on the annotation configuration, or looking up @CitrusTestSource test methods based on the test source files themselves.

File and jar resources could be supported too, at least to a certain extent.

Tasks

  • Support file: resources.
  • Support jar: resources.
  • It doesn't matter if the referenced files are in the project or not. IntelliJ can open them regardless.

Navigation from YAML test file to JUnit/TestNG test method

Summary

There is already some support on JUnit/TestNG methods to navigate to non-Java DSL test source files. The inverse could be supported as well.

Tasks

  • Implement an action that would navigate from a YAML test file to its corresponding JUnit/TestNG method.
  • The action could be assigned the Ctrl+Shift+T (on Windows) shortcut, the same one can navigate back and forth between source and test files in Java code.
  • Take into account if there are more than one JUnit/TestNG method covering the YAML file. In that case show a list of the matching methods, so that users can select which one to navigate to.
    • NOTE: this may also help uncover that a YAML test is executed multiple times by multiple methods.
  • The action would work only for files that are actual Citrus YAML tests.
    • For this, all @CitrusTestSource annotations in the project must be examined and indexed in some way, so that they can be properly matched to YAML files.

Scope

  • Only the YAML DSL is in scope for this issue. XML and Groovy DSLs will be handled in separate issues.

Inspections around injected Citrus resources

Summary

There are various types of resources that can be injected by Citrus, like Citrus, TestCaseRunner, endpoints, and others.

In order to identify usage issues earlier, one or more inspections could be useful.

Tasks

  • Create one or more inspections with the following checks:
    • A field is annotated with @CitrusFramework but the field type is not Citrus.
      • This prevents injecting the Citrus object into the field.
    • A field is annotated with @CitrusEndpoint but the field type is not Endpoint or one of its inheritors.
      • This prevents injecting an Endpoint object into the field.
    • A field is annotated with one of the @*EndpointConfig annotations but it is not annotated with @CitrusEndpoint.
      • This prevents injecting an Endpoint object into the field, and then be able to override its properties.
    • A field has as type one of the inheritors of Endpoint but the @*EndpointConfig annotation on the field doesn't match the type.
      • E.g. DirectEndpoint field annotated with @CamelEndpointConfig.

Extend the support for properties in `citrus-application.properties`

Summary

There is already some code completion support for citrus-application.properties, but that configuration file has more potential for integration with the IDE.

Tasks

  • Code completion for boolean property values
  • Implement regex language injection to pattern property values.

Settings for `@CitrusTestSource` method generation

Summary

#2 introduced an action to generate @CitrusTestSource test method but its behaviour is not customizable at the moment.

Tasks

  • Create plugin settings with the following options
    • Enable/disable the action, so that if a project doesn't use non-Java DSLs, then it doesn't appear for the users.
      • It would be enabled by default.
    • Make the the list of DSLs to be suggested customizable (to have enabled only those ones that are actually used in the project), so that when the action is invoked, unncessary items are not displayed.
      • At least one item must be enabled in the list.
      • If there is only one DSL enabled, there will be no code completion, and the template insertion won't stop at that template variable in order to speed up users' workflows.

Support Citrus function and validation matcher annotations in more file types

Summary

After #20 and #21, Citrus templating features are still supported only in Java files. To address this, supported for additional file types/language could be added.

Tasks

  • Add annotation support for the following languages:
    • Citrus DSLs:
      • xml
      • yaml
      • groovy
    • Others
      • json
  • These languages should be customizable in the plugin settings introduced in #21.

TBD

  • Determine exactly what language elements should be supported and annotated.

Plugin settings to toggle Citrus functions and validation matchers annotators

Summary

Citrus functions and validation matchers are currently highlighted in Java String literal, but there is no option to disable them in case users want to disable them.

Tasks

  • Add two options in the plugin settings:
    • one to enable/disable the annotator for Citrus functions
    • another one enable/disable the annotator for validation matchers
  • The options would be enabled by default.
  • Take into consideration the scalability of these options for when the annotators would be available in other file types in the future.

Run line marker for YAML test files

Summary

To be able to execute a Citrus YAML test from .yaml test files themselves, a run line marker could be implemented.

Tasks

  • Implement a RunLineMarkerContributor that would be displayed in the first line of the YAML test file.
    • The first line is the straightforward choice since one YAML test file can contain only one test case.
  • For this, all @CitrusTestSource annotations in the project must be examined and indexed in some way, so that they can be properly matched to YAML files.
    • This is also mentioned in #25.

Notes

Scope

  • Only the YAML DSL is in scope for this issue. XML and Groovy DSLs will be handled in separate issues.

Extend code completion of properties in `citrus-application.properties`

Summary

Besides CitrusSettings, there are other classes that hold and provide Citrus configuration properties. To make the integration more comprehensive, code completion for the properties in those classes should also be provided.

Tasks

  • Extend the current code completion with properties from the following classes:
    • org.citrusframework.report.HtmlReporterSettings
    • org.citrusframework.report.JUnitReporterSettings
    • org.citrusframework.report.SummaryReporterSettings
    • org.citrusframework.report.TestReporterSettings
    • org.citrusframework.CitrusSpringSettings
    • org.citrusframework.ftp.FtpSettings
    • org.citrusframework.http.server.HttpServerSettings
    • org.citrusframework.json.JsonSettings
    • org.citrusframework.mail.MailSettings

Inspections for the @CitrusTestSource annotation

Summary

Certain issues could be detected by static analysing the configuration of @CitrusTestSource annotations.

Tasks

  • Create an inspection that can detect the following:
    • invalid test type
    • if a value in name is the same as the test method's name, the value from name can be removed.
    • if packageName is the same as the package of the current test class, the packageName attribute can be removed.
    • the file extension associated with the test type must not be specified at the end of the values in name.
    • the file extensions in sources must match the file extension of the test type in type.
    • the same files in name and sources may be deduplicated.

Language injections in XML and Spring XML DSLs

Summary

There are many XML attributes that accept expressions of XPath, JsonPath, and many other languages. Those attribute values could be injected with the proper languages.

Tasks

Add language injection for following XML tag attributes:

  • JsonPath in k8s:validate.k8s:element@path in 'http://www.citrusframework.org/schema/kubernetes/testcase'
  • Shell Script in ssh-request.command in 'http://www.citrusframework.org/schema/ssh/message'
  • JsonPath in message.expression@path in XML when the sibling message tag's type attribute is json
  • JsonPath in receive.validate.json-path@expression in XML when the sibling message tag's type attribute is json
  • JsonPath in zookeeper:info.zookeeper:validate.zookeeper:json-path@expression in 'http://www.citrusframework.org/schema/zookeeper/testcase'
  • XPath in receive.message.validate.xpath@expression in Spring XMLs
  • Regex in step@given/when/then in 'http://www.citrusframework.org/schema/cucumber/testcase'
  • Groovy in actions/template.groovy in XML and Spring XML DSLs
  • Groovy in actions.send/receive.message.builder when the type attribute is set to groovy in Spring XMLs
  • Groovy in variables/create-variables.variable.value.script when the type attribute is set to groovy in XML and Spring XML DSLs
  • Groovy in message.validate.script when its type attribute is groovy in Spring XMLs
  • XML in transform.xml-data/xslt-data in Spring
  • XML in transform.source/xslt in non-Spring
  • JavaScript in selenium:javascript.selenium:script
  • JSON in selenium.fill-form.json in non-Spring XMLs

Look into `@CitrusSpringXmlTestFactory` and `CitrusTestFactorySupport`

Summary

CitrusTestFactorySupport is a fairly new solution, while @CitrusSpringXmlTestFactory has been around. Look into how they are processed and should be used, and implement integrations for them.

Tasks

  • CitrusTestFactorySupport
    • Line marker for CitrusTestFactorySupport.[springXml()|xml()|groovy()].[dynamicTest()|packageScan()|etc.] calls to navigate to the referenced resources.
      • This would work the same as the line marker for @CitrusTestSource test methods.
    • Inspection and quick fixes to replace .factory(...) calls to .xml(), .springXml() or .groovy() calls.
    • Inspection to report invalid test types in .factory(...).
    • Inspection to report file extensions in test names inside CitrusTestFactorySupport.dynamicTest[s]().
      • This is not required for groovy tests.
    • Inspection to report dynamicTests() with no test name provided.
    • Inspection to report packageScan() with no package name provided.
  • @CitrusSpringXmlTestFactory
    • Inspection: if a non-CitrusTestFactorySupport.springXml() method is called in a test method annotated with @CitrusSpringXmlTestFactory, then the annotation must be reported because it may mislead users about the contents of the test method.
    • Update the @CitrusTestFactory annotation related inspection to support @CitrusSpringXmlTestFactory as well.
    • Create a Generate @CitrusSpringXmlTestFactory Method action based on the @CitrusTestFactory Method action.
      • This action should be available only when the citrus-junit5 package is available.

Improve Citrus functions and validation matchers annotators

Summary

Although Citric provides annotators to highlight Citrus function and validation matcher expressions, they don't work well for when they are nested in each other.

Tasks

  • Investigate how the annotator could be improved for nested cases.
  • See how Citrus resolves these expressions to get an idea for the annotators:
    • org.citrusframework.context.TestContext#replaceDynamicContentInString(java.lang.String, boolean)
    • org.citrusframework.variable.VariableUtils
    • org.citrusframework.functions.FunctionUtils
    • org.citrusframework.validation.matcher.ValidationMatcherUtils

Custom citrus-application.properties files

Summary

Citrus supports defining custom locations for the citrus-application.properties file. Support for custom locations could be added, so that

  • code completions,
  • inspections,
  • language injections,
  • and custom project view icons

are available for them.

Tasks

  • Add a textfield or table in the Citrus plugin settings UI to be able to add custom Citrus settings file locations.
  • The location paths
    • when starting with / (forward slash), would be treated as paths relative to the project root. This would add IDE support for these specific files.
    • when not starting with /, would be treated as file names without their paths. This would add IDE support for all files having the configured names.
  • citrus-application.properties would be supported regardless of the presence of any additional paths/file names in the plugin settings.

Resources

Create file type for .msgs message trace file

Summary

Citrus provides a feature to trace incoming and outgoing messages with its dedicated file extension .msgs.
To prepare for and to support advanced features like language injections, code folding of messages, and potential other stuff, create a dedicated file type for this file extension.

Tasks

  • Create a new file type for .msgs files.

Feature ideas for .msgs files

  • Code folding of message sections.
  • Language injections for response bodies (if can be properly identified).
  • Number of messages in a given .msgs file, and maybe other statistics as e.g. Project View node decoration.

Citrus Quarkus support

Summary

Citrus v4 add Quarkus runtime support.

Tasks

  • Introduce JUnit5 specific Citrus Quarkus test framework.
  • Inspection: If the test class is annotated with @org.citrusframework.quarkus.CitrusSupport but not with @QuarkusTest, then it is probably an issue to report.
  • Inspection: A test class annotated with @QuarkusTest but not with @org.citrusframework.quarkus.CitrusSupport, and when the class has Citrus specific injected fields like @CitrusFramework, @BindToRegistry, etc. then the class must be reported to be annotated as @CitrusSupport too.
  • Inspection: report @com.consol.citrus/org.citrusframework.junit.jupiter.CitrusSupport used on a @QuarkusTest annotated test class, instead of @org.citrusframework.quarkus.CitrusSupport.

Preliminary support for `@CitrusTestFactory` annotation

Tasks

  • Add an action into the Alt+Insert Generate menu to be able to generate @CitrusTestFactory annotated Citrus JUnit5 test methods.
  • Create inspections for the annotation, if any necessary.
  • Extend existing inspections to handle and take into account this annotation.

Resources

Citrus 4.2.1 support

Summary

Citrus 4.2.1 has recently been released. See what changes need to be made in accordance.

Tasks

  • HttpClientResponseActionBuilder#response(org.springframework.http.HttpStatus) has changed to HttpClientResponseActionBuilder#response(org.springframework.http.HttpStatusCode).
  • HttpMessageBuilderSupport#status(org.springframework.http.HttpStatus) has changed to HttpMessageBuilderSupport#response(org.springframework.http.HttpStatusCode).
  • HttpServer#resourceBase no longer has a default value.
  • WebServiceServer#resourceBase no longer has a default value.

Resources:

Action to select arbitrary `@CitrusTestSource` method to run a yaml test file with

Summary

Althought there is run line marker to run yaml test files, at the moment it doesn't recognize non-classpath resources in the sources attribute of the @CitrusTestSource annotation. Also, the lookup logic might fail to recognize a test method as matching for any reason.

To improve on these cases, a separate action would be useful, with which users could choose an arbitrary @CitrusTestSource test method they would like to execute the current file with.

Tasks

  • Create a new action to run an arbitrary test method, and add this action to the yaml run line marker.
  • Either
    • present a list of test classes to the user to select from, and then separately the @CitrusTestSource methods from that class, or
    • present the list of all @CitrusTestSource methods in the project in one go.
  • The gradle task selection popup must work here too.

Implement existing Java DSL functionality for the XML DSLs

Summary

There are many current functionality in Citric (inspections, code completions, etc.) that could be applicable to the XML DSLs as well.

Resources:

  • XSD of XML DSL: runtime/citrus-xml/src/main/resources/org/citrusframework/schema/xml/testcase/citrus-testcase.xsd
  • XSD of Spring XML DSL: core/citrus-spring/src/main/resources/org/citrusframework/schema/citrus-testcase.xsd

Extend function and validation matcher completion to other file types

Summary

Currently function and validation matcher code completion is available only in Java String literals. Since they can be used in many other places, extend the list of them.

This would enable the feature e.g. in separate request and response body files.

Tasks

  • Create new completion contributors for the following file types and locations
File type Location
XML Tag texts, tag attribute values
JSON String literals
YAML Plain text, single-quoted and double-quoted strings
Groovy Single-, double-, triple-single-, triple-double-quoted strings

Inspections for `@*EndpointConfig`, `@*ClientConfig` and `@*ServerConfig` annotations

Summary

There are a handful of @*EndpointConfig / @*ClientConfig / @*ServerConfig annotations whose parser classes throw exceptions if the annotation configuration is not valid. In order to signal those invalid configurations, an inspection could be useful.

Tasks

  • Add one or more inspections for the validating the following annotations:
    • @JmsEndpointConfig
    • @JmsSyncEndpointConfig
    • @KafkaEndpointConfig
    • @HttpClientConfig
    • @HttpServerConfig
    • @WebServiceClientConfig

Extend the list of XML attributes to show resource line markers

Summary

There are already line markers in the XML and Spring XML DSLs on attributes that accept Citrus resource paths. This issue is to extend the list of supported tags and attributes.

Tasks

Add Run/Debug actions line marker in Citrus XML files

Summary

Citrus YAML and Groovy files already have line markers to run/debug corresponding Java test methods. It is time for the XML DSL to have that feature.

Tasks

  • Add the run/debug line marker to Citrus XML files.
  • Support both regular XML and Spring XML files as well.
  • The line marker should be added to:
    • the <test> tag in case of regular XML files. This is a top-level tag, so there will only be one per file.
    • the <testcase> tags in case of Spring XML files. This is not a top-level tag, so there may be more than one of them.
      • can the @CitrusTestSource annotation configuration distinguish between them inside the same XML file?

Check and add support for Citrus 4.2.0

Summary

Citrus 4.2.0 is out, so let's check its changes and support the ones we can.

Tasks

  • Test sharding
    • Code completion of new system properties in citrus-application.properties:
      • Properties: citrus.sharding.total, citrus.sharding.number, citrus.sharding.seed
      • Description of them are available in the javadoc of the ShardingConfiguration class.
      • These properties must be completed only when Citrus 4.2.0 is available in the project. The same solution may be used as for CLI command completion in WireMocha.
    • Inspections:
      • citrus.sharding.number: This should be a value between 0 and the total number of shards minus one.
        • Report less than 0 values.
        • If citrus.sharding.total is specified in the citrus-application.properties, report invalid max numbers according to that value.
      • Total number of shards must be at least 1.

Resources

Code completion of citrus: functions

Summary

Citrus provides dedicated, so-called functions for generating data at various locations. These are prefixed with citrus:. To simplify the discovery of these functions, code completion could be implemented.

Tasks

  • Implement code completion to suggest the list of available Citrus functions.
  • The completion would be invoked in string literals where the preceding text is citrus:, and ideally citrus:.* with arbitrary text after the prefix for which it is true that at least one of the functions start with that text.
  • For now, it would work only in the Java DSL.
  • For now, it would not support custom function prefixes.

Resources

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.