What is the order of code execution in Citrus test cases - citrus-framework

While developing Citrus test cases (Citrus version 2.7.2 on Linux) I noted that methods seem to be executed in a different order than specified in code. This is an example of a test:
#CitrusTest
public void testOrderOfMethods() throws InterruptedException {
log.info(">> Starting test");
http()
.client(wiremockClient)
.send()
.get("/__admin/requests")
.accept("application/json");
http()
.client(wiremockClient)
.receive()
.response(HttpStatus.OK)
.messageType(MessageType.JSON);
log.info(">> Test completed");
Thread.sleep(2000);
log.info(">> Waited a while");
}
The output produced by this code is:
14:35:19 14:35:19,133 INFO citrus.Citrus|
14:35:19 14:35:19,133 INFO citrus.Citrus|
14:35:19 14:35:19,145 DEBUG t.TestContextFactory| Created new test context - using global variables: '{}'
14:35:19 14:35:19,145 INFO junk.JunkIT| >> Starting test
14:35:19 14:35:19,146 INFO junk.JunkIT| >> Test completed
14:35:21 14:35:21,146 INFO junk.JunkIT| >> Waited a while
14:35:21 14:35:21,146 INFO citrus.Citrus|
14:35:21 14:35:21,146 INFO citrus.Citrus|
14:35:21 14:35:21,146 DEBUG citrus.Citrus| STARTING TEST JunkIT.testOrderOfMethods <esb.junk>
14:35:21 14:35:21,146 INFO citrus.Citrus|
14:35:21 14:35:21,146 DEBUG citrus.TestCase| Initializing test case
So, the 3 log lines (Starting test, Test completed, Waited a while) are printed before the Citrus http() calls, even though the test waits 2 seconds before "Waited a while" is printed.
That's what happens if I run my test with Jenkins as a Maven job. If I run my test in a debugger, the order of statements is as suggested by the source code.
My question is: are calls to Citrus somehow executed after other code (on another tread maybe)? If so, how can I enforce the order of code in Citrus test methods?

You should use TestRunner instead of TestDesigner in Citrus.
The designer will first collect all test actions, construct the whole test case and execute it at the end of construction.
The runner will execute the actions immediately as they are constructed in the Java DSL method calls.
The different approaches and strategies of designer and runner are also described in more detail in the reference documentation: http://www.citrusframework.org/reference/html/#writing-test-cases-in-java

Related

Spring Batch Job Stop Using jobOperator

I have Started my job using jobLauncher.run(processJob,jobParameters); and when i try stop job using another request jobOperator.stop(jobExecution.getId()); then get exeption :
org.springframework.batch.core.launch.JobExecutionNotRunningException:
JobExecution must be running so that it can be stopped
Set<JobExecution> jobExecutionsSet= jobExplorer.findRunningJobExecutions("processJob");
for (JobExecution jobExecution:jobExecutionsSet) {
System.err.println("job status : "+ jobExecution.getStatus());
if (jobExecution.getStatus()== BatchStatus.STARTED|| jobExecution.getStatus()== BatchStatus.STARTING || jobExecution.getStatus()== BatchStatus.STOPPING){
jobOperator.stop(jobExecution.getId());
System.out.println("###########Stopped#########");
}
}
when print job status always get job status : STOPPING but batch job is running
its web app, first upload some CSV file and start some operation using spring batch and during this execution if user need stop then stop request from another controller method come and try to stop running job
Please help me for stop running job
If you stop a job while it is running (typically in a STARTED state), you should not get this exception. If you have this exception, it means you have stopped your job while it is currently stopping (that is what the STOPPING status means).
jobExplorer.findRunningJobExecutions returns only running executions, so if in the next line right after this one you have a job in STOPPING status, this means the status changed right after calling jobExplorer.findRunningJobExecutions. You need to be aware that this is possible and your controller should handle this case.
When you tell spring batch to stop a job it goes into STOPPING mode. What this means is it will attempt to complete the unit of work chunk it is currently processing but then stop working. Likely what's happening is you are working on a long running task that is not finishing a unit of work (is it hung?) so it can't move from STOPPING to STOPPED.
Doing it twice rightly leads to an Exception because your job is already STOPPING by the time you did it the first time.

boofuzz - Target connection reset, skip error

I am using boofuzz to try to fuzz a specific application. While creating the blocks etc and some testing i noticed that the target sometimes closes the connection. This causes procmon to terminate the target process and restarts it. However this is totally unnecessary for this target.
Can i somehow tell boofuzz to not handle this as an Error (so target is not restarted)
[2017-11-04 17:09:07,012] Info: Receiving...
[2017-11-04 17:09:07,093] Check Failed: Target connection reset.
[2017-11-04 17:09:07,093] Test Step: Calling post_send function:
[2017-11-04 17:09:07,093] Info: No post_send callback registered.
[2017-11-04 17:09:07,093] Test Step: Sleep between tests.
[2017-11-04 17:09:07,094] Info: sleeping for 0.100000 seconds
[2017-11-04 17:09:07,194] Test Step: Contact process monitor
[2017-11-04 17:09:07,194] Check: procmon.post_send()
[2017-11-04 17:09:07,196] Check OK: No crash detected.
Excellent question! There isn't (wasn't) any way to do this, but there really should be. A reset connection does not always mean a failure.
I just added ignore_connection_reset and ignore_connection_aborted options to the Session class to ignore ECONNRESET and ECONNABORTED errors respectively. Available in version 0.0.10.
Description of arguments available in the docs: http://boofuzz.readthedocs.io/en/latest/source/Session.html
You may find the commit that added these arguments informative for how some of the boofuzz internals work (relevant lines 182-183, 213-214, 741-756): https://github.com/jtpereyda/boofuzz/commit/a1f08837c755578e80f36fd1d78401f21ccbf852
Thank you for the solid question.

How to stop and resume a spring batch job

Goal : I am using spring batch for data processing and I want to have an option to stop/resume (where it left off).
Issue: I am able to send a stop signal to a running job and it gets stopped successfully. But when I try to send start signal to same job its creating a new instance of the job and starts as a fresh job.
My question is how can we achieve a resume functionality for a stopped job in spring batch.
You just have to run it with the same parameters. Just make sure you haven't marked the job as non-restarted and that you're not using RunIdIncrementer or similar to automatically generate unique job parameters.
See for instance, this example. After the first run, we have:
INFO: Job: [SimpleJob: [name=myJob]] completed with the following parameters: [{}] and the following status: [STOPPED]
Status is: STOPPED, job execution id 0
#1 step1 COMPLETED
#2 step2 STOPPED
And after the second:
INFO: Job: [SimpleJob: [name=myJob]] completed with the following parameters: [{}] and the following status: [COMPLETED]
Status is: COMPLETED, job execution id 1
#3 step2 COMPLETED
#4 step3 COMPLETED
Note that stopped steps will be re-executed. If you're using chunk-oriented steps, make sure that at least the ItemReader implements ItemStream (and does it with the correct semantics).
Steps marked with allowRestartWithComplete will always be re-run.

SBT to run Play app exits immediately when started using scala.sys.process.run?

I am writing an integration test that needs to start up several applications. One of these applications is a Play one as a SBT project called appA.
I am able to start the app on the right port using scala.sys.process as follows:
import scala.sys.process._
import org.scalatest._
class Main extends FeatureSpec with Matchers{
val app = Seq("sbt", "project appA", "run 7777").run
println(app.exitValue)
}
The spawned application however exits immediately with return value 0. No errors are displayed to the console. I just see:
[info] play - Listening for HTTP on /0:0:0:0:0:0:0:0:3000
(Server started, use Ctrl+D to stop and go back to the console...)
[success] Total time: 1 s, completed Feb 27, 2014 10:26:56 PM
0
The 0 at the end of the output is from calling exitValue on the created process. exitValue blocks until the spawned process exits.
How can I run the Play application without it exiting immediately? Is there a better way to start the application?
SBT has 2 run modes - interactive and batch. If you run without any args it goes to interactive mode and does not exit. When you run it by passing commands it runs in a batch mode and exits when the last command is complete. It does not matter if your application inside SBT runs in a forked JVM or not.
Thus to "fix" it you can apply this hack: add ~ command to the end of the list of sbt commands/args:
val app = Seq("sbt", "project appA", "run 7777", "~").run
~ is used to watch source code for changes and recompile when it happens. Thus SBT will never exit unless stopped by a user or killed.
A cleaner way would be to run Play application in a Jetty container (assuming you have WAR to run) or such by calling a main class that starts up Jetty with a command like java com.example.MyMain but that requires additional setup.

How to kill a JUnit test run in Eclipse that has entered an infinte loop

I have some Java code that I am unit testing using JUnit, running inside Eclipse (Neon). It so happens that some code under test has a bug in it, causing it to enter an infinite loop. The JUnit run then, of course, does not finish. How do I kill the test run?
The button for stopping the test run ("Stop JUnit Test Run") does not work well: the GUI seems to think that it has stopped the test run, but a look at the CPU activity (using top, for example), shows that a Java thread is still running. I can kill the thread myself by sending it a kill signal. But that seems a kludge and is inconvenient. Is there a better way, available within Eclipse itself?
Kill it from the console view, using the red button. This stops the process.
Stopping it from the junit view only asks it to stop.
You can handle such things with JUnit by specifying a time-out within
the #Test annotation. For example:
// Simple test-case which will always fail with time-out
#Test(timeout = 1000 * 60) throws Exception // 60 seconds
public void testSomething() {
for (int i = 0; i < 100; i++) { // 100 seconds
Thread.sleep(1000);
}
}
If your test method doesn't finish on time,
then JUnit will interrupt it and report a test failure.
For the example above it will be:
java.lang.Exception: test timed out after 60000 milliseconds
at java.lang.Thread.sleep(Native Method)
at my.package.Test1.testSomething(Test1.java:12)
First, try Matthew Farwell's answer. If that doesn't work then you have to go to your processes running (ctrl+shift+esc on windows, then processes tab) and select the java.exe task, then end process. In the event you ever need to kill eclipse, it's javaw.exe