| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reporter was probably named 'xunit' based on the historical use of
xUnit to refer to testing frameworks derived from Smalltalk's SUnit.
These frameworks typically added their own prefix, e.g. JUnit for Java,
RUnit for R, etc.
The most popular of these was the JUnit framework, and the corresponding
XML output produced by the Ant built tool became somewhat of a de facto
standard, which is probably why we chose to model our reporter after it.
Nowadays however, naming it 'xunit' is problematic as there is actually
a testing famework named xUnit.net, typically shortened to, you guessed
it: xunit.
Test report consumers will typically have a junit mode, and an xunit
mode, and the latter could easily be mistaken for what testlib outputs,
unless we clarify this.
The clarification also allows us to safely extend our support for the
JUnit XML format to incorporate some elements that are nowadays common,
but where we are lagging behind the standard.
[ChangeLog][QTestLib] The formerly named 'xunitxml' test reporter has
been renamed to what it actually is: a JUnit test reporter, and is now
triggered by passing -o junitxml to the test binary.
Change-Id: Ieb20d3d2b5905c74e55b98174948cc70870c0ef9
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This produces:
********* Start testing of tst_QtJson *********
Config: Using QtTest library 5.3.0, Qt 5.3.0 (Feb 13 2014, GCC 4.6.3, 64 bit, debug build)
PASS : tst_QtJson::initTestCase()
<?xml version="1.0" encoding="UTF-8"?>
<TestCase name="tst_QtJson">
<Environment>
<QtVersion>5.3.0</QtVersion>
<QtBuild>Qt 5.3.0 (Feb 13 2014, GCC 4.6.3, 64 bit, debug build)</QtBuild>
<QTestVersion>5.3.0</QTestVersion>
</Environment>
<?xml version="1.0" encoding="UTF-8" ?>
<testsuite errors="1" failures="1" tests="42" name="tst_QtJson">
<properties>
<property value="5.3.0" name="QTestVersion"/>
<property value="5.3.0" name="QtVersion"/>
<property value="Qt 5.3.0 (Feb 13 2014, GCC 4.6.3, 64 bit, debug build)" name="QtBuild"/>
</properties>
<Environment>
<QtVersion>5.3.0</QtVersion>
<QtBuild>Qt 5.3.0 (Feb 13 2014, GCC 4.6.3, 64 bit, debug build)</QtBuild>
<QTestVersion>5.3.0</QTestVersion>
</Environment>
[ChangeLog][QtTest] Tests now output build information.
Change-Id: I0ab473371575f2b807db725256805b8bffea3454
Reviewed-by: Sergio Ahumada <sahumada@blackberry.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
|
|
|
Automated tests often need to load some data from external files.
Currently, a wide variety of approaches for this have been used in Qt
autotests, including:
- embed the source directory into the test binary at compile time, and
find the testdata relative to that; this fails when the source tree
is no longer available (e.g. when the tests are deployed to a device).
- use a path relative to the current working directory, and trust that
the caller always sets the current working directory such that the
testdata can be found; this fails when the caller uses a different
working directory than expected.
- use a path relative to QCoreApplication::applicationDirPath();
this fails when source tree != build tree (since testdata is not
automatically copied into the build tree).
- compile the files into the binary using the Qt resource system; this
should work, but does not allow for testing of code which genuinely
needs external files.
It seems that there is not a simple method for determining the testdata
path which can be reliably used in all circumstances, so various tests
have reinvented the testdata location method in different ways.
Therefore, this is a good candidate for an addition to the testlib API.
The current implementation of QFINDTESTDATA is able to find testdata
in all three of (build tree, install tree, source tree), in that order.
Change-Id: Ib2fed860723ccf437240da3b00db22dfe1a6b56c
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
|
