As far as I understand(beginner level on Spring Cloud Contract), the contract tests generated from the groovy contracts are with junit.
What if I want to use TestNG? Basically I want to group my tests with TestNG annotation #Test(groups="unit") and #Test(groups="contract") in order to separate unit tests and contract tests using ssomething like mvn test -Dgroups=unit and mvn test -Dgroups=contract.
Thank you for your help.
Currently, we don't support this out of the box. You would have to write your own org.springframework.cloud.contract.verifier.builder.SingleTestGenerator implementation (by extending, for example, the JavaTestGenerator and referencing it in spring.factories file) but that can be quite time-consuming, unfortunately.
Related
is there any possibility to annotate / tag the CDC generated tests?
I would like to group the cdc tests and execute them as separate step in my build pipeline.
They are all present under target or build and then /generated-test-sources/contracts. You can by default exclude those paths and have a separate profile in maven or task in gradle that will include those paths when you want to run contract tests
I want to start using the framework Spring Cloud Contract for contract testing. But does Spring Cloud Contract support JavaScript and JMS?
I haven't found any information about this.
As for the JMS, we do support it either via spring-integration or Apache Camel. You can also write your own JMS support. It's enough to register a couple of beans.
As for Javascript and non-jvm languages. There's no out of the box support but we have a process for that. The workflow is described here (in those cases the consumer is a Java app but in the next section I'll describe how the flow would differ) - https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract.html#_common_repo_with_contracts or https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract.html#_step_by_step_guide_to_cdc. We will try to obviously simplify the process but currently there's a bunch of manual tasks to be done (not very tedious though).
The consumer can very easily download and run the stubs. Just clone https://github.com/spring-cloud-samples/stub-runner-boot, build it and push the fat jar to your Nexus/Artifactory. This application will be used by the consumers to automatically download stubs and run them locally. As a consumer you can then call java -jar stub-runner-boot --stubrunner.ids="com.example.groupid:artifactid:classifier:version:8090" --stubrunner.repositoryRoot="http://localhost:8081/artifactory/libs-release-local" . That way the application will start, download the provided jar with stubs from the given address where your artifactory is. Now your front end application can call the stubs of the producer at localhost:8090.
Of course we will try to simplify the cloning and pushing process (https://github.com/spring-cloud/spring-cloud-contract/issues/37) etc. but for now you have to do those 2 steps manually.
UPDATE:
With this article https://spring.io/blog/2018/02/13/spring-cloud-contract-in-a-polyglot-world we're presenting a way how to work in a polyglot environment. It's enough to use the provided docker images to run contract tests against a running application and to run the stub runners too.
I am using Citrus TestNGCitrusTestDesigner, I have a few classes annotated with #Test. Each class have a few methods. Each method annotated #Test and #CitrusTest. When I am configuring tests that should be executed during mvn clean package integration-test - I am changing #Test(enabled=true) to true or false. How can I do this more effectively? I found this doc: http://www.citrusframework.org/reference/1.0/html/testsuite.html#testsuite-tasks but it is for an old version. Doesn't work in Citrus Framework 2.X.
Citrus runs with TestNG or JUnit framework. This means that you can reuse the mechanisms of these frameworks in order to group tests or define a test suite.
With TestNG for instance you can use different groups of tests or create a testng.xml file that defines the tests to execute in a suite (http://testng.org/doc/documentation-main.html#testng-xml).
With TestNG or JUnit integration in build tools like Maven or Gradle the tests are executable from command line or Java IDE.
In one vein of thought I would like to configure a build with a custom task that will serve instead of the test default task. I will not be registering it as an "sbt test framework" as I'd like to avoid the syntax, limitations and history that comes with that. For example I'd like more flexibility in formatting, storing and sending test results.
Would it be possible introducing an sbt task to mimic sbt's default test task, in the following essential senses:
depend on compilation
be a dependency for other tasks such as artifact publishing tasks, and have them depend on a success return value from it
be able to provide it with library dependencies which will be excluded from final publishable artifacts
be able to control it just like any other task dependency
etc
Alternatively, are you able to delineate the structure of the mostly undocumented sbt TestFramework interface to a level that it's straightforward having your own formatting, test output logic, and test results publishing code, in your TestFramework implementation? I have mostly failed locating scalaTest's implementation of it.
Thanks in advance for you answers on both techniques.
I use Simpletest test suites to run all tests, with different configuration methods. I've created one suite per config method, and it sets up the environment and then runs all tests.
Take a look at Adapter.php and Constants.php if that's unclear.
Now there seems to be support for test suites in PHPUnit, but as I understand it, it's merely for grouping tests with no support for setting up the environment or running PHP scripts.
How can I convert my test suites to PHPUnit? I'm open to rethink how the tests are structured :)
You can use test fixtures to setup your environment either before each test, or before each test suite:
http://www.phpunit.de/manual/3.6/en/fixtures.html#fixtures.more-setup-than-teardown
The methods you are looking for are
setUp() and tearDown() (called before/after each single test), and
setUpBeforeClass() and tearDownAfterClass() (called before/after each test class (suite)).
Apart from restructuring your test suite you should also be aware that the behaviour of the assertions in PHPUnit is different from SimpleTest.
While in SimpleTest you can test on an assertions result and execute further code after a failed assertion, you cannot in PHPUnit: test the return value of a method that triggers an error with PHPUnit
This will likely also force refactoring some of the actual tests.