You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
Sandro Tosi 92fe647e52 grammar fixes/improvements; patch by Vilius Panevėžys; Closes: #811193 5 years ago
..
HowToReportGoodBugs.txt add a document listing some web resources for providing good bug reports; thanks to martin f krafft for the report; Closes: #446168 12 years ago
README.Users grammar fixes/improvements; patch by Vilius Panevėžys; Closes: #811193 5 years ago
README.developers implement support for attachments in bugscripts; thanks to Joachim Breitner for the report and to Michael Stapelberg for the patch; Closes: #526110 7 years ago
README.source fix them to be valid reStrucuturedText files; thanks to Jakub Wilk for the report; Closes: #563051 12 years ago

README.source

Source layout
=============

The source tree for ``reportbug`` is organised this way:

* Top level

* Manual pages.

* Debian packaging

* ``debian/`` contains the control files used to build the Debian
source and binary packages.

* Programs

* ``bin/`` contains the end-user programs (e.g. ``reportbug``,
``querybts``).

* Libraries

* ``reportbug/`` contains the Python library module package used by
the programs.

* `Unit testing framework`_

* ``test/`` contains the unit test suite. Unit test modules are
discovered and run using the ``nosetests`` program, and are named
as ``test_*.py``.

* Internal checking framework

* ``checks/`` contains various scripts that ensure reportbug's
internals are up-to-date with the Debian BTS.

* Internationalisation and localisation

* ``po4a/`` contains configuration and data for localisation of
source files using the ``po4a`` tool.

Unit testing framework
======================

The reportbug source package now has a unit testing framework.

The directory ``test/`` contains unit test modules and supporting
files. New unit test modules should be added to this directory and
named ``test_*.py``.

The unit test suite depends on the `python-nose` package being
installed, to make the ``nosetests`` command available. The unit tests
themselves can be written using either the `unittest` or `doctest`
modules in the standard Python library.

The `scaffold` module (from the ``test/scaffold.py`` file) contains
some helper functionality for unit tests, including an extended
`TestCase` class.

``make`` targets for testing and quality checks
-----------------------------------------------

The following ``make`` targets are useful for testing and related
tasks.

* ``make test`` runs the unit test suite, preceded by a timestamp
banner, and reports any test failures or "OK" if all tests pass.

* ``make test-continuous`` starts a loop which clears the screen, runs
``make test``, then waits for any of the tests or source code to
change, and starts the loop again.

This is useful to run in a separate terminal during a development
session, so that whenever a change is made the test suite will be
run automatically. You might want to keep the window hidden while
actually editing files, and only look at it when you've created or
modified a file and want to check its effect on the test run.

This uses the ``inotifywait`` command from the `inotify-tools`
package to wait for `create` and `modify` events.

* ``make coverage`` runs the test suite and collects test coverage
information, then reports the current statement coverage of the test
suite.

This requires the `python-coverage` package to be installed. See its
documentation for more about its operation.

* ``make pyflakes`` runs the `pyflakes` static code checker on all
Python files found in the project tree.

This requires the `pyflakes` package to be installed. See its
documentation for more about its operation.

* ``make pylint`` runs the `pylint` code checker on all code modules
and programs.

This requires the `pylint` package to be installed. See its
documentation for more about its operation.


..
Local Variables:
coding: utf-8
mode: rst
End:
vim: filetype=rst :