Citrusframework - Java action - Get result - citrus-framework

Besides REST-API Calls, I need to call my own Java-Class, which basically does something, which I want to confirm later in the test via REST-API-Calls.
When calling my Java-Class, there is an expected behavior: It may fail or not fail, depending on the actual Test-Case.
Is there any chance to code this expectation this into my test-class:
java("com.org.xyz.App").method("run").methodArgs(args).build();
As this is the Main-Class, which should be executed later in a automated fashion, I would prefer to validate the Return-Code.
However, I'm looking for any possible way (Exception-Assertion, Stdout-Check, ..) to verify the status of the program.

As you are using the Java DSL to write test cases I would suggest to go with custom test action implementation and/or initializing your custom class directly in the test method and call the method as you would do with any other API.
You can wrap the custom code in a custom AbstractTestAction implementation as you then have access to the TestContext and your custom code is integrated into the test action sequence.
The java("com.org.xyz.App").method("run").methodArgs(args) API is just for compliance to the XML DSL where you do not have the opportunity to initialize own Java class instances. Way too complicated for your requirement in my opinion.

Related

Is it possible to get the test results of a job using the Java API for Jenkins?

I'm looking at the Jenkins API for java and I see there's a JobApi to start/stop Jobs and a BuildInfo interface with information about a build in that job. I can't find anything to get the test results of a build though, is it not (yet) implemented or did I miss it?
I mean the results that you would get by calling the endpoints:
http://<server>/job/<job_name>/<build_number>/testReport/api/json?pretty=true --> returns a hudson.tasks.junit.TestResult
http://<server>/job/<job_name>/<build_number>/testReport/<package>/BugReportsTest/<test_class>/api/json?pretty=true --> returns a <hudson.tasks.junit.CaseResult>
What is being received is a Java Object. One needs to call the isPassed() to get whether this particular object passed or not.
Refer to the Javadoc here
https://javadoc.jenkins.io/plugin/junit/hudson/tasks/junit/TestResult.html
This is pretty similar to case result as well where again isPassed() to be used to check whether it has passed or not.
Refer to Case Result Javadoc here
https://javadoc.jenkins.io/plugin/junit/hudson/tasks/junit/CaseResult.html
You can know whether the entire build job has passed or not by using the following url:
http://<server>/job/<job_name>/<build_number>/api/json?pretty=true
A snapshot for entire build has passed or not is as follows:

#karate How to pass parameter to a feature file in gatling simulation class?

Let's consider a scenario, we have to run the performance test for "create an account api" which takes input as header/path param "Auth token" and input data like user account name . So for above scenario we have 2 feature file as,
to run performance test for POST http://baseUrl/auth_param/create/input_data
1. One feature(e.g: generateAuth.feature) file which will have the auth
token
2. Second feature(createAccount.feature) file which take parameter as a
auth token, input data.
Here is my simulation class,
class <MyClass> extends Simulation {
before {
println("Simulation is about to start!")
}
val generateAuthTest = scenario("generateAuth").exec(karateFeature("classpath:path/generateAuth.feature"))
val createAccountTest = scenario("test").exec(karateFeature("classpath:path/createAccount.feature"))
setUp(
createAccountTest.inject(rampUsers(1) over (10 seconds))).maxDuration(1 minutes)
after {
println("Simulation is finished!")
}
}
Here, can i read auth from generateAuth.feature file which is input for createAccount.feature file, so that i can pass as a parameter?
Please suggest me how to pass parameters to createAccount.feature while calling in karateFeature method.
Let me put a requirement here,
let's say we have some feature files for CRUD operations on a particular data. Here how i go to write functional scenario,
I will create new feature file to write a scenario
just use CRUD files to test a SINGLE flow.
Now if i go for Performance test cases on individual operation, i feel there are 2 ways,
Create new 4 performance test feature files (one for each CRUD
method) and call these CRUD feature files in the respective test
feature file. Finally we just call test feature files in the
respective gatling simulation class.
**(In this case, I will end up with creating more test feature files as well simulation classes for
performance, which I want to avoid) **
Just call CRUD files in the respective gatling simulation class and
pass the required parameters to them.(In this case , we just need to create only 4 simulation
classes and run them on the basic of operation like create,read,delete and so on)
Here just wanted to know 2nd way of performance test, is it achievable or not in karate and if yes please let me know how?
Summary- I think its achievable using 3rd feature file (extra) for
individual use case but I do not want to make an extra feature file
for each case so that I can avoid maintenance work and can take
advantage of re-usability of existing feature file from functional
test to performance test.
Just use the normal Karate concepts such as karate-config.js
You can easily switch environments by setting the karate.env system property.
For example:
mvn test -DargLine="-Dkarate.env=e2e"
EDIT: after you edited your question, it is clear you have a SINGLE flow you want to test. please use a SINGLE feature. I suggest you move the generateAuth into the Background of the feature. Also refer to the docs on callSingle() for advanced options.
If you are expecting 2 feature files to magically share data that is not possible and not needed if you structure your tests correctly.
If you really really need this, please create a Java singleton and access it from each feature. Totally don't recommend this though.
EDIT: In Karate 0.9.0 onwards, you can call a single scenario within a feature if it has a tag:
classpath:animals/cats/create.feature#sometagname

GWT Async generation, turn off in some cases?

When using gwt-maven-plugin's generateAsync, is it possible to apply an annotation (or something) to an individual gwt-rpc service so that the corresponding async isn't auto-generated and can be written manually?
Alternatively, is there an annotation (or something) that makes the generated asyncs have the "Request" return type?
From the gwt-maven-plugin's documentation you need to adjust the servicePattern configuration property, or you can ask it to always generate methods returning Request.
Or, even better, don't use this goal!
(or only call it manually once in a while and copy the generated classes to your sources)
The GWT Generators will never create a class if one already exists with that name. This means you can ask GWT to compile and generate the code, then copy the classes into your sources and customize them, and later compiler runs will not attempt to generate sources.
This may have other side effects - if the proxy, typeserializer, or fieldserializer is prevented from being generated, then the RPC generators may assume that other dependencies have also all been correctly generated, so you may find yourself missing classes if you don't also copy those other classes. Likewise, of course any changes that require your serializers being modified or rebuilt will have to be done manually, such as changing a serializable type, or modifying a RPC method.
Your async interface can always declare a return type of Request or RequestBuilder instead of void. If you declare RequestBuilder, then the request will not be sent automatically, and you must call send(), whereas a Request returned means that the request has been sent.

Should I simulate FE request in Functional Testing in TYPO3?

I'm trying to understand concepts of Functional Testing in a scope of TYPO3 and overall.
My intention is to test Controller of my extension. For simplicity let's imagine, that it has only two methods: listAction() and addAction($object).
I've checked some Core tests and one of them was EnableFieldsTest from Extbase, which does following: loads some special crafted extension, simulates FE (via special JsonRenderer.ts), which calls listAction() of that extension and the output (specail JSON) is examined then.
So, I decided to do same with my Controller, simulated FE, which called my listAction(). The only difference is that my extension doesn't use JSON View, but usual Fluid, which produces HTML.
To make it work as expected I need either:
Make significant changes in my extension, so it outputs JSON in Testing context, but this seems kinda hacky for me.
Do not use provided HasRecordConstraint from the Core, but simply examine HTML, that was output with assertContains(), which also seems hacky.
Create customized version of my extension, which outputs expected JSON and use it only as Fixture. But this makes such test useless at all.
Therefore I'm stuck at this point and need to understand:
Is it right to simulate FE request, like I do, or I'm now out of Functional Testing concept?
In case I want to test object creation via addAction($object) and ensure, that f.e. a request to a REST service is made, should I stub that Service or I can catch a call somehow different?
Since TYPO3 8, acceptance tests are integrated which are more the thing you want to have.
Use functional tests to call the action and check the return value of that but don't use a frontend
Use acceptance tests to call the frontend and check the HTML output of your plugin.
The best would be to check out the acceptance tests of the core.

How can I write a code generator in Ceylon

I want to write a code generator that generates a class based on the meta model of another ceylon class. I want the code generator to run at compile time. What is the best way for me to do this. I could probably accomplish this by writing a plugin for gradle or the ceylon build system but I'm hoping for a simpler solution. Unfortunately, I don't see any support for code generators in ceylon. Also, are there any plans for code generators in ceylon?
I want to write this code generator because I'm thinking about writing a simple web framework for ceylon that look at a class like the following using the meta-model:
controller
shared class Controller() {
shared void doSomething() => print("did it!");
}
I plan for it to be like Spring MVC. This framework would make a restful API from the Controller class that allows someone to write an AJAX call like this:
$http.get("/Controller/doSomething");
I want to make things more convenient, high level, and simple by doing something like GWT. I want to create a code generator that automatically generates a class like this:
shared class RemoteController() {
shared void doSomething() {
$http.get("/Controller/doSomething");
}
}
The RemoteController would be run in a user's browser as javaScript and allow client side ceylon code to do an Ajax call like this:
RemoteController().doSomething();
That would end up calling the Controller().doSomething() on the server so "did it!" would be printed.
AST Transformers have been proposed, but are still in the early design phase. For now, to do compile-time code generation, you’ll have to rig up something of your own.
To actually generate the code, I would recommend use of ceylon.ast and ceylon.formatter. The workflow would roughly be:
analyze source code –
either parse it with ceylon.ast (ceylon.ast.redhat::compileAnyCompilationUnit) and analyze it without typechecking,
or parse it using the compiler, run the typechecker, then convert it to ceylon.ast (ceylon.ast.redhat::anyCompilationUnitToCeylon), keeping the typechecker information using the new update hooks in the very soon upcoming 1.2.0 release
edit the source code AST to add your new code (using a custom ceylon.ast.core::Editor that injects new class definitions into the CompilationUnits), or perhaps create entirely new compilation units if the RemoteController lives in a different module
convert the ceylon.ast AST to a compiler AST and feed it into ceylon.formatter to turn the AST into code again (see here for an example of that)
Alternatively, if you integrate this into your build step, you could skip the ceylon.formatter part of step 3 and instead feed the converted compiler AST into the typechecker and rest of the compiler directly.