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

From Qt Wiki
Jump to navigation Jump to search
(Add "cleanup" tag)
(Convert ExpressionEngine links)
Line 11: Line 11:
== Autotest Structure ==
== Autotest Structure ==


Whenever something is submitted to "Gerrit":https://codereview.qt.io/, it will be tested by [[CI-Configurations|CI System]].
Whenever something is submitted to [https://codereview.qt.io/ Gerrit], it will be tested by [[CI-Configurations|CI System]].


The testing is done by executing tests located under <code>tests/auto/</code>.
The testing is done by executing tests located under <code>tests/auto/</code>.

Revision as of 15:06, 4 March 2015

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

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:

  1. It is easy to locate the test for a particular class.
  2. 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.)

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:

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