New-Unit-Test-Structure: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
[[Category:Developing_Qt::QA]] | |||
= | = New Unit Test Structure for Qt = | ||
== Introduction == | |||
This article focuses on the structure beneath <code&gt;tests/auto/&lt;/code&gt; so that you know exactly where to put your tests. | |||
== Autotest Structure == | |||
The testing is done by executing tests located under | Whenever something is submitted to "Gerrit&quot;:https://codereview.qt.io/, it will be tested by [[CI-Configurations|CI System]]. | ||
The testing is done by executing tests located under <code&gt;tests/auto/&lt;/code&gt;. | |||
Questions to ask: | Questions to ask: | ||
| Line 25: | Line 27: | ||
# It is easy to test a certain functional area in isolation. | # It is easy to test a certain functional area in isolation. | ||
Consider the | Consider the <code&gt;QMutex&lt;/code&gt; class for example. This resides in <code&gt;src/corelib/thread/&lt;/code&gt; and the corresponding test is located under <code&gt;tests/auto/corelib/thread/qmutex/&lt;/code&gt;. | ||
As another example, | As another example, let's say that you have made a change that is likely to affect code under <code&gt;src/corelib/&lt;/code&gt; only. You can now execute a recursive test runner (such as '<code&gt;make check&lt;/code&gt;') locally from <code&gt;tests/auto/corelib/&lt;/code&gt; 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.) | ||
==Current state== | == Current state == | ||
By the time of this writing, test restructuring has been done for QtBase only (and there is still a bit<br /> cleanup to be done). The principle should be applied to other modules as well, and will be the responsibility<br /> of the Qt community as a whole. | By the time of this writing, test restructuring has been done for QtBase only (and there is still a bit<br />cleanup to be done). The principle should be applied to other modules as well, and will be the responsibility<br />of the Qt community as a whole. | ||
The test structure in QtBase currently looks essentially like this: | The test structure in QtBase currently looks essentially like this: | ||
<code><br />auto<br /> corelib<br /> animation<br /> qabstractanimation <— tests for 'qabstractanimation' go here<br /> qanimationgroup<br /> …<br /> …<br /> thread<br /> qmutex <— tests for 'qmutex' go here<br /> qsemaphore<br /> …<br /> …<br /> dbus<br /> gui<br /> integrationtests<br /> network<br /> opengl<br /> other<br /> sql<br /> testlib<br /> tools<br /> xml<br /> v8<br /></code> | |||
Revision as of 10:07, 24 February 2015
New Unit Test Structure for Qt
Introduction
This article focuses on the structure beneath <code>tests/auto/</code> so that you know exactly where to put your tests.
Autotest Structure
Whenever something is submitted to "Gerrit":https://codereview.qt.io/, it will be tested by CI System.
The testing is done by executing tests located under <code>tests/auto/</code>.
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 <code>QMutex</code> class for example. This resides in <code>src/corelib/thread/</code> and the corresponding test is located under <code>tests/auto/corelib/thread/qmutex/</code>.
As another example, let's say that you have made a change that is likely to affect code under <code>src/corelib/</code> only. You can now execute a recursive test runner (such as '<code>make check</code>') locally from <code>tests/auto/corelib/</code> 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.)
Current state
By the time of this writing, test restructuring has been done for QtBase only (and there is still a bit
cleanup to be done). The principle should be applied to other modules as well, and will be the responsibility
of the Qt community as a whole.
The test structure in QtBase currently looks essentially like this:
<br />auto<br /> corelib<br /> animation<br /> qabstractanimation <— tests for 'qabstractanimation' go here<br /> qanimationgroup<br /> …<br /> …<br /> thread<br /> qmutex <— tests for 'qmutex' go here<br /> qsemaphore<br /> …<br /> …<br /> dbus<br /> gui<br /> integrationtests<br /> network<br /> opengl<br /> other<br /> sql<br /> testlib<br /> tools<br /> xml<br /> v8<br />