Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.
New Unit Test Structure: Difference between revisions
(Removed cleanup notice) |
Paulwicking (talk | contribs) (Remove temporal words, reword structure example section slightly to reflect the fact that this _is_ actually the structure for all modules, and not only for qtbase.) |
||
| Line 31: | Line 31: | ||
As another example, let's say that you have made a change that is likely to affect code under <tt>src/corelib/</tt> only. You can now execute a recursive test runner (such as '<tt>make check</tt>') locally from <tt>tests/auto/corelib/</tt> and thus save time by running only the tests that are likely to be sensitive to the change. (Of course, at some point, a full test run needs to be executed, but that can happen less frequently.) | As another example, let's say that you have made a change that is likely to affect code under <tt>src/corelib/</tt> only. You can now execute a recursive test runner (such as '<tt>make check</tt>') locally from <tt>tests/auto/corelib/</tt> and thus save time by running only the tests that are likely to be sensitive to the change. (Of course, at some point, a full test run needs to be executed, but that can happen less frequently.) | ||
== | == Structure Example == | ||
The structure as described on this page applies to all Qt modules, and keeping it that way is the responsibility of the Qt community as a whole. | |||
of the Qt community as a whole. | |||
As an example of the structure, the test structure in QtBase looks essentially like this: | |||
<code> | <code> | ||
Latest revision as of 08:01, 3 October 2018
New Unit Test Structure for Qt
Introduction
This article focuses on the structure beneath tests/auto/ so that you know exactly where to put your tests.
Autotest Structure
Whenever something is submitted to Gerrit, it will be tested by CI System.
The testing is done by executing tests located under tests/auto/.
Questions to ask:
- Where to put the test for my new class?
- Where is the test for the class containing my new function?
The proposed answer to these questions is:
The directory structure of the tests should resemble the directory structure of the Qt source itself as much as possible.
The structural resemblance has two advantages:
- It is easy to locate the test for a particular class.
- It is easy to test a certain functional area in isolation.
Consider the QMutex class for example. This resides in src/corelib/thread/ and the corresponding test is located under tests/auto/corelib/thread/qmutex/.
As another example, let's say that you have made a change that is likely to affect code under src/corelib/ only. You can now execute a recursive test runner (such as 'make check') locally from tests/auto/corelib/ and thus save time by running only the tests that are likely to be sensitive to the change. (Of course, at some point, a full test run needs to be executed, but that can happen less frequently.)
Structure Example
The structure as described on this page applies to all Qt modules, and keeping it that way is the responsibility of the Qt community as a whole.
As an example of the structure, the test structure in QtBase looks essentially like this:
auto
corelib
animation
qabstractanimation <— tests for 'qabstractanimation' go here
qanimationgroup
...
...
thread
qmutex <— tests for 'qmutex' go here
qsemaphore
...
...
dbus
gui
integrationtests
network
opengl
other
sql
testlib
tools
xml
v8