IUP ISI/MediaWiki-Silk/Test Architecture

From KDE Community Wiki
Revision as of 15:46, 2 November 2010 by Manik971 (talk | contribs) (→‎Local test server)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Test types

We decided to do 2 types of tests, firstly we use unit tests for each classes to ensure that code meets its design and behaves as intended.

Secondly, we decided to make code coverage test, it describes the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing. We add code coverage because it’s easily set and it increases code visibility and quality.

Folder organisation

We will create a test folder in each project folder. For example, in the libmediawiki folder we will create a test folder, named “test” (“mediawiki/libmediawiki/test”). For each classes, a test class file will be created.

Tools

We will use CTest to execute tests, it’s a cross-platform, open-source testing system distributed with CMake. CTest can peform several operations on the source code, that include configure, build, perform set of predefined runtime tests. It also includes several advanced tests such as coverage and memory checking.

We have decided to use CTest to work with the same distribution as CMake.

The test ouput results will be displayed on a console or with XML and HTML.

Unit test

In the unit test code, we have decided to use QTest because we wanted as much as possible to use the Qt library to avoid dependency with other library.

Code coverage test

For the code coverage we will use GCov, it’s a code coverage program, it will allow us to easily add new tests and to automate tests execution.

Local test server

To run tests we need a server, we decided to implement a local server (fake server). In opposition to a web server, here are local server advantages :

  • Environment independence, we not depend on a web server then there is not Internet problems because latency can increase the test execution period and make our tests unusable. Moreover our local server don’t need any maintenance operation.
  • Keep control on data, tester can keep control on data and avoid that data could be forged by any other tester.