gergely/taskwarrior-2.x
1
0
Fork 0
Code Issues Actions Packages Projects Releases 1 Wiki Activity

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 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 All unit tests produce TAP (Test Anything Protocol) output, and are run by the
'run_all' test harness. 'run_all' test harness.
@@ -65,7 +67,7 @@ are:
useful than feature tests, and more likely to contain overlapping coverage. useful than feature tests, and more likely to contain overlapping coverage.
* Eliminate obsolete tests, which are tests that have 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 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: 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 * 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 on https://bug.tasktools.org/ and should include the issue ID in a
docstring or comment. 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. * Class and method names should be descriptive of what they are testing.
Example: TestFilterOnReports Example: TestFilterOnReports
* Docstrings on Python tests are mandatory. The first line is used as title * 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 * Extra information and details should go into multi-line docstrings or
comments. 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 in a script named tw-XXXX.t. Later, someone will incorporate that test
script into higher-level feature tests. 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 * 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 should not do the same by iterating over the entire problem space. It is a