-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathTODO
61 lines (48 loc) · 2.09 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
-- next big thing --
-- backlog --
+ ++ API one-line report format for dying/warning
++ + MOD multiline like
+ ++ MOD port Test::Differences to refute
+ ++ TST Even more examples
++ ++ API todo() or $TODO - don't slow down passing tests!
++ ++ MOD Round-trip assertion
++ ++ MOD Util::Tempfile - preserve file if tests fail
+++ + API If contract with args fails, display args
+++ + API Optional short-circuit on first failure
+++ + API Some extra goodies to contract {...} like title
+++ + API verbosity switch to include more/less info in report
+++ + API bail_out() - can die for now, only needed for Unit
++ +++ DRV add Test-based driver
++ +++ MOD Provide what Test::Most can
++ +++ MOD import Test::Builder-based tests
+++ +++ DRV A TAP consumer class
+++ +++ DRV Own Unit-testing backend (adhere TAP::Harness)
+++ +++ MOD async_ok "event id" => [ prerequisite1, prerequisite2 ]
-- need to think more --
+++ + MOD `is_unique` - make a string unique within current contract
+++ +++ MOD Module to check that "foo" is really implementation of "bar"
-- this file's structure --
{priority} {complexity} {TAG} {brief feature/bug description}
# *Priority* _decreases_ from `+` to `+++`
The questions to ask oneself:
* Can 1.0 ship without this?
* Is not having this done awkward?
* Are there users asking for this?
* Do other features depend on this?
# *Complexity* _increases_ from `+` to `+++`
The questions to ask oneself:
* What is the simplest meaningful example?
* How should this be tested/documented?
* What extra knowledge is required for this?
* What other features does this depend upon?
# *Tag* is 3 uppercase letters
Known tags are (also used in commit messages):
* **API** - extending API
* **MOD** - condition/check arsenal
* **DRV** - test backends/drivers
* **BLD** - own builder features/bugs
* **REF** - refactoring, internal structure changes, optimisations
* **DOC** - improving documentation, use case descriptions
* **TST** - adding tests/examples
* **BUG** - bugfix
* **AUX** - changing distribution files (Makefile, README, xt tests etc)