I need to keep verbose level at 2, but now the TestNG console output includes:
[RemoteTestNG] detected TestNG version 6.14.3
...
... TestNG 6.14.3 by Cédric Beust (cedric#beust.com)
...
I've already tried creating my own listener which extends TestListenerAdapter and implements IAlterSuiteListener.
Changing the verbose level within the overridden alter() method does work, but it sets the level too early, its the same as if I had manually set the level within the testng.xml file. (If I set verbose to 0 here, it would remain at 0, and not 2, while running tests. If I set it to 2, then it brings us right back to square 1.)
Trying to change the verbose level within the overridden onStart() / onFinish() methods, does not seem to make any difference at all, it just goes ignored.
Is there a way to avoid these headers at the start of testing while still keeping verbose level at 2 during testing?
Thanks!
I found a temporary work around
I omitted the "verbose" attribute from the "Suite" element
I added "verbose=2" to each "Test" element
This does not hide
[RemoteTestNG] detected TestNG version 6.14.3
But it does hide
...
... TestNG 6.14.3 by Cédric Beust (cedric#beust.com)
...
And test output to console is as expected for verbose level 2
Related
RobotFrameWork:
by means of this Symbol: # it is possible to comment lines
But I don't want to comment lines but skip temporary (for test purposes of the test) from running...
How dan I do that?
(I don't want te mix the lines that have to stay commented with the lines that are temp. comment to not run in the run).
I would pass a flag to robot framework which can be used on lines you want to temporarily stop executing:
robot --variable TEMP_STOP:True smoke_tests.robot
Then in your code add the following snippet on lines you want to skip temporarily for that run:
Run Keyword If '${TEMP_STOP}'!='True' Log Logs If not True
Also ensure there is a default value for the variable in your suite otherwise you will get and error. Thanks for mentioning this in the comments #TodorMinakov
*** Variables ***
${TEMP_STOP} False
To re-enable those lines then you can just pass:
robot --variable TEMP_STOP:False smoke_tests.robot
In all fairness this should be solved through commenting your code by selecting the entire set of code and commenting that and reverse-commenting that same section. This will 'double comment' existing comments and when you reverse the comment on the entire block this will remain commented. In the below example I use RED, but any IDE with support for Robot Framework Script will behave similarly.
Code:
*** Test Cases ***
My Test Case
Log To Console Uncommented Start Keyword
# Log To Console Permanent Commented Keyword
Log To Console Temporary Commented Keyword
# Log To Console Permanent Commented Keyword
Log To Console Temporary Commented Keyword
Log To Console Uncommented End Keyword
Then we comment the section we want, notice the double comments:
Now we reverse the same section by selecting it and perform the toggle (un)comment:
I want to skip some phpunit tests in scrutinizer.
How can I achive the same?
Where do I need to do configuration changes for the same?
Many CI systems incl. Scrutinizer CI set environment variables in their build environment.
For example the environment variable SCRUTINIZER is set to TRUE. That is only one of many, learn more about Pre-defined Environment Variables on Scrutinizer CI.
Inside the test method (or inside the setUp() method for the whole class) you can check the environment variable (e.g. via $_ENV) and mark the test as skipped.
if (isset($_ENV['SCRUTINIZER'])) {
$this->markTestSkipped(
'Scrutinizer CI build'
);
}
See as well the more general question How to skip tests in PHPunit? and the Phpunit documentation Incomplete and Skipped Tests.
In my case, I have added
./vendor/bin/phpunit --exclude-group Group1, Group2 command as follows in .scrutinizer.yml file at application level to skip phpunits representing these groups as follows :
build:
nodes:
acsi:
tests:
override:
- './vendor/bin/phpunit --exclude-group Group1, Group2'
- phpcs-run --standard=phpcs.xml
- php-scrutinizer-run
I'm having problem understanding how to correctly set the COMPILE_DEFINITIONS target properti in CMake.
my target is add_library(modelutilities STATIC ${modelutilities_SRCS})
I if use
set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} ${Qt5Widgets_COMPILE_DEFINITIONS})
set_target_properties(modelutilities PROPERTIES
VERSION "0.0.1"
SOVERSION 0
EXPORT_NAME "ModelUtilities"
ARCHIVE_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/lib"
LIBRARY_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/lib"
RUNTIME_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/bin"
COMPILE_DEFINITIONS ${modelutilities_COMPILE_DEFINE}
)
everything works fine, but if I add another line between them with set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} MODELUTILITIES_LIB) it stops working complaining that set_target_properties was called with the wrong number of arguments.
Anyone can spot what I'm doing wrong?
P.S.
I already tried using doublequotes: set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} "MODELUTILITIES_LIB"). It did not change anything
P.P.S.
If I message(STATUS ${modelutilities_COMPILE_DEFINE}) QT_WIDGETS_LIB;QT_GUI_LIB;QT_CORE_LIB in the first case and QT_WIDGETS_LIB;QT_GUI_LIB;QT_CORE_LIB;MODELUTILITIES_LIB in the second
With newer version of CMake, what is being preached is the idea of targets. So, for example, instead of include_directories() it's now preferred to use target_include_directories().
That being the case I think you'd be better served using the preferred target_compile_definitions() to set compile definitions for your utilities library.
One advantage you get is that your can scope your compile definitions using the PUBLIC or PRIVATE keywords.
I'm getting this on the console in a QML app:
QFont::setPointSizeF: Point size <= 0 (0.000000), must be greater than 0
The app is not crashing so I can't use the debugger to get a backtrace for the exception. How do I see where the error originates from?
If you know the function the warning occurs in (in this case, QFont::setPointSizeF()), you can put a breakpoint there. Following the stack trace will lead you to the code that calls that function.
If the warning doesn't include the name of the function and you have the source code available, use git grep with part of the warning to get an idea of where it comes from. This approach can be a bit of trial and error, as the code may span more than one line, etc, and so you might have to try different parts of the string.
If the warning doesn't include the name of the function, you don't have the source code available and/or you don't like the previous approach, use the QT_MESSAGE_PATTERN environment variable:
QT_MESSAGE_PATTERN="%{function}: %{message}"
For the full list of variables at your disposal, see the qSetMessagePattern() docs:
%{appname} - QCoreApplication::applicationName()
%{category} - Logging category
%{file} - Path to source file
%{function} - Function
%{line} - Line in source file
%{message} - The actual message
%{pid} - QCoreApplication::applicationPid()
%{threadid} - The system-wide ID of current thread (if it can be obtained)
%{qthreadptr} - A pointer to the current QThread (result of QThread::currentThread())
%{type} - "debug", "warning", "critical" or "fatal"
%{time process} - time of the message, in seconds since the process started (the token "process" is literal)
%{time boot} - the time of the message, in seconds since the system boot if that can be determined (the token "boot" is literal). If the time since boot could not be obtained, the output is indeterminate (see QElapsedTimer::msecsSinceReference()).
%{time [format]} - system time when the message occurred, formatted by passing the format to QDateTime::toString(). If the format is not specified, the format of Qt::ISODate is used.
%{backtrace [depth=N] [separator="..."]} - A backtrace with the number of frames specified by the optional depth parameter (defaults to 5), and separated by the optional separator parameter (defaults to "|"). This expansion is available only on some platforms (currently only platfoms using glibc). Names are only known for exported functions. If you want to see the name of every function in your application, use QMAKE_LFLAGS += -rdynamic. When reading backtraces, take into account that frames might be missing due to inlining or tail call optimization.
On an unrelated note, the %{time [format]} placeholder is quite useful to quickly "profile" code by qDebug()ing before and after it.
I think you can use qInstallMessageHandler (Qt5) or qInstallMsgHandler (Qt4) to specify a callback which will intercept all qDebug() / qInfo() / etc. messages (example code is in the link). Then you can just add a breakpoint in this callback function and get a nice callstack.
Aside from the obvious, searching your code for calls to setPointSize[F], you can try the following depending on your environment (which you didn't disclose):
If you have the debugging symbols of the Qt libs installed and are using a decent debugger, you can set a conditional breakpoint on the first line in QFont::setPointSizeF() with the condition set to pointSize <= 0. Even if conditional breakpoints don't work you should still be able to set one and step through every call until you've found the culprit.
On Linux there's the tool ltrace which displays all calls of a binary into shared libs, and I suppose there's something similar in the M$ VS toolbox. You can grep the output for calls to setPointSize directly, but of course this won't work for calls within the lib itself (which I guess could be the case when it handles the QML internally).
I installed VisualPHPUnit as described here. I'm using XAMPP.
define('PEAR_PATH', 'c:\xampp\php\pear');
define('TEST_DIRECTORY', 'C:\xampp\htdocs\visualphpunit\tests');
When I run, I see no text, only nicely formatted blanks. Haven't been find-by-google anyone else who has reported an empty rendering of the VisualPHPUnit screen.
Left side shows "
VisualPHPUnit
Tests-------------
Options ------------
Archives -----------
Graphs -------------
And the right side is a big blank.
Running phpunit from command-line works fine.
C:\xampp\htdocs>phpunit visualphpunit\tests
PHPUnit 3.6.10 by Sebastian Bergmann.
..foo { breaks: this } barI.some stuffFsome stuffES
Time: 0 seconds, Memory: 3.25Mb
There was 1 error:
C:\xampp\htdocs\visualphpunit\tests\PUTest.php:8
C:\xampp\php\phpunit:46
FAILURES!
Tests: 7, Assertions: 5, Failures: 1, Errors: 1, Incomplete: 1, Skipped: 1.
C:\xampp\htdocs>
NSinopoli (developer of VisualPHPUnit) here.
It's strongly recommended to report any bugs/issues with VPU on the project's issue tracker.
That said, #edorian's diagnosis is incorrect - having output in your tests does not break VPU. (It's actually collected and rendered below the results of the test that contains it.)
"When I run, I see no text, only nicely formatted blanks" - did you select any tests in the file selector before clicking "Run Tests"? Running VPU without selecting any tests will get you the blanks you've described. If that's not the case, are you running the tests with any "Options" selected? If so, there could be a configuration issue which is preventing proper rendering of the results.
You have output in your tests. As far as i remember this breaks VisualPHPUnit because it damages the json log file used by VisualPHPUnit.
Remove the output from your tests and it should work