GothenburgBitFactory/taskwarrior
1
0
Fork 0
mirror of https://github.com/GothenburgBitFactory/taskwarrior.git synced 2025-06-26 10:54:26 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Docs: Updated README

Browse source
This commit is contained in:
Paul Beckingham 2015-10-25 11:34:12 -04:00
parent cb381bf388
commit c6b5576194
1 changed files with 13 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

20
test/README
View file

@ -8,7 +8,9 @@ test suite.
Running Tests
-------------
TL;DR cd test && make && ./run_all && ./problems
Do this to run all tests:
$ cd test && make && ./run_all && ./problems
All unit tests produce TAP (Test Anything Protocol) output, and are run by the
'run_all' test harness.
@ -65,7 +67,7 @@ are:
useful than feature tests, and more likely to contain overlapping coverage.
* Eliminate obsolete tests, which are tests that have overlapping coverage.
This means migrate bug-specific tests to feature tests.
There is simply no point in testing a feature twice, in the same manner.
What Makes a Good Test
@ -81,18 +83,22 @@ Conventions for writing a test
If you wish to contribute tests, please consider the following guidelines:
* For a new bug, an accompanying test is very helpful. Suppose you write up
a bug, named TW-1234, then the test would be a script named tw-1234.t, and
based on the template.t example.
Over time, we will migrate the tests in tw-1234.t into a feature-specific
test script, such as filter.t, export.t, whichever is appropriate.
* Tests created after bugs or feature requests should (ideally) have an entry
on https://bug.tasktools.org/ and should include the issue ID in a
docstring or comment.
* Tests should be added to the file that best matches the "thing" being
tested. For instance, a test on filters should live in filter.t
* Class and method names should be descriptive of what they are testing.
Example: TestFilterOnReports
* Docstrings on Python tests are mandatory. The first line is used as title
of the test.
of the test. Include the issue ID - there are many examples of this.
* Extra information and details should go into multi-line docstrings or
comments.
@ -124,7 +130,7 @@ Here are some guildelines that may help:
in a script named tw-XXXX.t. Later, someone will incorporate that test
script into higher-level feature tests.
* If the command line parser is not working, always blame the Lexer.
* If the command line parser is not working, start by blaming the Lexer.
* While the lowest level (C++) tests should be exhaustive, higher level tests
should not do the same by iterating over the entire problem space. It is a