Quality

From GNUpdf
Revision as of 19:37, 2 March 2010 by Jemarch (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Contents

Overview

The quality of both the software and documentation produced in the context of the GNU PDF project is a big concern for us. We are working hard to follow several quality-driven procedures for use in the development of software and in the generation of useful documentation.

GNU Coding Standards

Since the GNU PDF project is part of the GNU Project, all the software written in the project conform to the guidelines exposed in the GNU Coding Standards (or GCS).

Aspects covered by the GCS are:

  • Common behaviour for GNU programs
  • Guidelines to write portable code
  • Guidelines to write reliable code
  • Guidelines to write robust code
  • Documentation of programs
  • The release process

The GNU Coding Standards also attempt to make the GNU system clean, consistent and easy to install.

Requirements

The requirements of the library are built in the proposed client API. Having a full specification of the client API of the library allow us to have complete and quite formal specs.

An automatic report on API Consistency is generated daily, in order to ease the identification of missing functions in the implementation.

Testing

We are following a bottom-up testing strategy. The verification of the software is performed in the following steps:

  1. Unit testing is performed in order to verify the low-level modules of the library.
  2. Subsystem testing is performed in order to verify the combinatio of several subsystems.
  3. System testing is performed in order to verify the whole system (library) through its API.

An eventual acceptance testing could be done using client-provided testcases.

An automatic report with the results of the run of the unit tests is generated daily.

In order to identify potentially buggy and untestable functions a report on the cyclomatic complexity of the codebase is generated daily.

Finally, a report on the code coverage is used to identify functions with missing unit tests.

Personal tools
Namespaces

Variants
Actions
project
Tools