Qt Unit tests - show only failed ones - qt

Is it possible that Qt only outputs the Unit Tests that have failed?
Right now I get a huge list that 140 have been passed and 3 have failed. I would like to only see the ones that have failed.

Use the -silent command line option. It only shows fatal errors, test failures and minimal status messages.

Related

VTS few test cases give syntax error unexpected 'newline' and module gets reported as incomplete (inspite of test cases pass)

/data/local/tmp/VtsHalBiometricsFaceV1_0TargetTest/VtsHalBiometricsFaceV1_0TargetTest.config[1]: syntax error: unexpected 'newline'
Total Tests : 1
PASSED : 1
FAILED : 0
IMPORTANT: Some modules failed to run to completion, tests counts may be inaccurate.
============== End of Results ==============
Issue : Test case is passing but module is not getting reported as completed.
Issue seen with only Android 11 based VTS suites and works well with older android flavor VTS suites.
Environment of 18.04.2 LTS ubuntu and few modules inspite of passing the test cases it does not report a module pass (only for few modules) and shows it as Done=false in results report.
Logs indicate this kind of errors pointing to various .config files.
Any idea / suggestion what could be issue ?
This was asked again in syntax error: unexpected 'newline' in .config file in android vts and that got an answer that if you've modified the vts-tradefed file, then this error appears.
Additionally I noticed that even chmod changes can cause this problem to appear.

Robot framework exit status of a command is wrong?

I'm trying to execute a command remotely through Robot Framework which is failing through Robot framework and giving me the wrong exit status of 13.
But if we run this manually exit status of TTman.sh is 112 which is actually pass(Not the standard return codes).
am I doing something wrong here?
You are not getting the remote code of the remote command, in fact the RC 13 you are getting from the run is most probably from the robotframework - on run completion its RC is the number of failed cases. I.e. 13 cases should have failed, when you observed this.
To get the return code of your command, a few changes in the case are needed; this is how the semi-last line should look like, with explanations below:
${rc}= Execute Command your_command_from_the_question &>/dev/null; echo $?
First, all the output of your command (stdout & stderr) is redirected to /dev/null - to not return it. Then the special var $? is printed - it holds the RC of the last executed command (and is available in most *sh variants, like bash).
Finally, that value is stored in the ${rc} robotframework variable, and you can do whatever checks you need on it, further in the case.
This approach has one drawback - as stderr is hidden, you will not be able to see any errors coming from running the command. But if it was not, then they would be interleaved with the RC, which would have required further processing of the {rc} var, to get the desired value. If you need it (the stderr output in case of failures), change accordingly.
P.S. don't add screenshots of a source in a question, it is much less usable than a text version.

sbt stops at first failed test (quick fail mode?)

Is it possible to make sbt stop at the first failed test?
For example, during a refactoring, I'd use that feature like this:
~quickFailTest
and I'd fix test after test.

Grunt Warning 6

Our automated build process incorporates a grunt task that periodically (more times than I'd like) generates a 6 return code.
According to the grunt web page 6 is a "Warning". Well okay, a warning for what? It's breaking our build since we would only pass on a 0 exit case. I'm looking at wrapping this in a script so I can catch this warning condition and generate a success exit code, though without any idea what the Warning might be I'm hesitant. It appears to work when I get this exit condition but would like a better understanding on what it may be.
Any ideas?
So this turned out to be an issue with grunt-contrib-less. I didn't recognize the associated less compiler error in our build log:
[39mnon_object_property_loadError: Cannot read property 'rules' of undefined in ../../XXXX/styles/modules/SomeLessFile.less on line null, column 0: [31m
Once I found this line a google search quickly found this in GitHub:
And have updated the grunt-contrib-less package. So far so good.
check http://gruntjs.com/api/grunt.fail:
If --stack is specified on the command-line and an error object was
specified, a stack trace will be logged.
Or try to run "grunt --verbose --force"

All the tests passed, but bamboo build fails with a statement "No failed tests found, a possible compilation error occurred."

I'm supposed to run some jbehave(automated) tests in bamboo. Once the tests run I'll generate some junit compatible xml files so that bamboo could understand the same. All the jbehave tests are ran as part of a script, because I need to run the jbehave tests in a separate display screen(remember these are automated browser tests). Example script is as follows.
Ex:
export DISPLAY=:0 && xvfb-run --server-args="-screen 0, 1024x768x24"
mvn clean integration-test -DskipTests -P integration-test -Dtest=*
I have one more junit parser task which points to the generated junit compatible xml files. So, once the bamboo build runs and even if all the tests pass, I get red build with the message "No failed tests found, a possible compilation error occurred."
Can somone please help me on this regard.
Your build script might be producing successful test reports, but one (or both, possibly) of your tasks is failing. That means that the failure is probably* occurring after your tests complete. Check your build logs for errors. You might also try logging in to your Bamboo server (as the bamboo user) and running the commands by hand.
I've seen this message in the past when our test task was crashing halfway through the test run, resulting in one malformed report that Bamboo ignored and a bunch of successful reports.
*Check the build log to make sure that your tests are indeed running. If mvn clean doesn't clean out the test report directory, Bamboo might just be parsing stale test reports.
EDIT: (in response to Kishore's links)
It looks like your task to kill Xvfb is what is causing the build to fail.
18-Jul-2012 09:50:18 Starting task 'Kill Xvfb' of type 'com.atlassian.bamboo.plugins.scripttask:task.builder.script'
18-Jul-2012 09:50:18
Beginning to execute external process for build 'Functional Tests - Application Release Test - Default Job'
... running command line:
/bin/sh
/tmp/FUNC-APPTEST-JOB1-91-ScriptBuildTask-4153769009554485085.sh
... in: /opt/bamboo-home/xml-data/build-dir/FUNC-APPTEST-JOB1
... using extra environment variables:
<..snip (no meaningful output)..>
18-Jul-2012 09:50:18 Failing task since return code was 1 while expected 0
18-Jul-2012 09:50:18 Finished task 'Kill Xvfb'
What does your "Kill Xvfb" script do? Are you trying something like pkill -f "[x]vfb"? pkill -f silently returns non-zero if it can't match the expression to any processes.
My solution was to make a 'script' task:
#!/bin/bash
/usr/local/bin/phpcs --report=checkstyle --report-file=build/logs/checkstyle.xml --standard=PSR2 ./lib | exit 0
Which always exits with status 0.
This is because PHP code sniffer return exit status 1 when only 1 coding violation (warning / error) is found which causes the built to fail.
Turns out to be a simple fix.
General bamboo behavior is to scan the entire log and see for any failure codes(1). For this specific configuration i had some 6 scripts out of which one of them was to kill the xvfb(frame buffer). For some reason server is not able to kill xvfb and that task was returning a failure code. Because of this, though all the tests passed, bamboo got one of this error codes from previous tasks and build was failing.
Current fix is to remove the task which kills xvfb and the build went green! \o/.

Resources