File: TODO

package info (click to toggle)
libtest-unit-perl 0.27-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 1,312 kB
  • sloc: perl: 4,297; makefile: 5
file content (303 lines) | stat: -rw-r--r-- 8,559 bytes parent folder | download | duplicates (6)
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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
PerlUnit TODO
=============

Here's our roadmap.  It should give you an idea of what is planned,
and in some cases when it's planned for and/or who's going to do it.
Only update this file on the main branch!

See also doc/consensus.txt.

* Before release 1.0

None of these are big jobs, but Adam thinks they should all be done
before 1.0 if we want the framework to gain respect and widespread
usage; after all, many people will check out PerlUnit for the first
time when they hear 1.0 being announced, and first impressions count
for a lot.

** Rename Test::Unit::HarnessUnit and Test::Unit::UnitHarness

Not sure what to yet, but we want to get these big API changes out of
the way before we bump the version number.

*** HarnessUnit
"A Test::Unit::Runner which outputs Test::Harness-style output"

Used for most of our self-tests.

***  UnitHarness
"A makeover of Test::Harness to allow its tests to be retrofitted as
unit tests".  Seems to need some work, but is neat for running t/*.t

What uses it?  I can't see anything here, but we may have real live
(and quiet) users.

It's referenced from T:U:Loader, but only used for certain inputs.

** Get working build on 5.7.2 and 5.8.0

Now seems happy on Debian 5.8.4-2, and I'll cheerfully let the
cpan-testers find out about the others.

** Rename do_run to run_suite

in the runners.

Is this to match T:U:Procedural and T:U:TkTestRunner ?

** Tidy up copyrights, credits, and licensing

We had copyrights, licenses, and out of date author attributions in
pretty much every file in the distribution.  Tidied up 2005-07 mca.

> It would be good to move all the copyrights and credits into one or
> two files (COPYING or LICENSE or AUTHORS, say),

There are still some single-author files:

  T:U:Assertion*

  T:U:Decorator
  T:U:Setup

  T:U:Tutorial

> and then to change the licensing/credit bits and pieces in all the
> other files into something which refers to that one file, and also
> states that none of the files should be distributed separately, only
> as an entire package, thereby preventing the copyright-containing
> file from being disassociated from the others.

Well I've done a chunk of that.  It's not clear that the project
licences need or seek to prevent dissociation of files from the
project.


* Document stuff better

** TestRunner::do_run should be public

Requested by Matthias Ferber, so that suites can be dynamically
generated by providing parameters.

** Filtering mechanism is poorly documented.

** Test::Unit::Tutorial is AWOL

** examples are old and sparse
Useful stuff has been on the lists...

** class diagram
We have one at doc/class-diagram.*

Dunno if it's much good.  Notes include specific TODOs at the bottom.


* Nice to have before 1.0

Some of these could be left until after 1.0.  Adam thinks it makes
sense to do them before the release, however; none of them are big
jobs.

** @TESTS isn't tested.

** Pinch more assertions from Test::More

I don't think there's even any particular reason against importing
them directly from Test::More.  No point in duplicating code across
CPAN modules without good reason.

I like these ones:

*** use_ok(), require_ok(), eq_set()

import straight in

*** is_deeply()

either import or write using FreezeThaw::cmpStr or Data::Compare
or whatever

*** eq_array(), eq_hash()

Hmm.  Test::Unit::Assertion::Array / Test::Unit::Assertion::Hash?

*** Easier assertion-set extensibility

mca: I extend test cases by having a standard (for me) superclass,
into which I pile assorted stuff.  It would be nice to provide such
functionality easily and without kinking everyone's inheritance tree.

Also, may need to avoid bloating the standard assertions set.  The
overhead for the compiler is small, but the learning curve ends up
looking much steeper than it needs to be.

Options...

 - provide "simple" and "hedgehog (bristling)" versions of TestCase

 - use import options to determine assertion set

 - leave them all in, but split the documentation

 - spread them into Piers' T:U:A:* structure...  need to investigate


** Rethink how the tests are split up between the t/*.t.

Currently we have t/all_tests.t, which is clearly a misnomer, and we
have some tests for the assertion code being run from that rather than
from t/assert.t.

** Test::Unit::Loader working with whole directories.

Test::Unit::Loader::load_test_dir() needs to be finished.

* After 1.0

No harm done if they end up being done before 1.0 though, of course.

** Test filtering

Piers suggested the beautiful idea of using Attribute::Handlers so you
could do things like:

  sub test_something : todo {...}
  sub test_something : skip_if(<condition>) {...}
  sub test_something : skip {...}

Adam needs this for work ASAP, and will probably implement it very soon.
There is already a primitive filtering mechanism in place which is
controlled by the filter() and filter_method() methods.

Update: Adam met up with Piers a few months ago and together they
figured out that Attribute::Handlers may be unusable due to its
magic happening in the BEGIN phase, whereas all user test code gets
compiled at run-time via Test::Unit::Loader.  Hmm.

** Tests to add

*** PerlUnit selftests

**** die errors that look like variable names  [mca]

A test that fails with an error like

  die '$lotsofdollars';

and make sure it gets wrapped into an ExceptionError

**** doing the right OOP thing in constructors and isa() checks

Possibly a test that overrides the 'isa' method so Piers' fix to my
patch

  (back to using $exception->isa(C) instead of UNIVERSAL::isa($exception,C))

can be exercised.

Also Adam has patched some of the PerlUnit constructors to allow
passing a classname instead of being invoked as a method.

**** check for broken Error.pm overloading of exceptions [as]

Older Error.pms don't do boolean overload, so

  eval { ... };
  if ($@) {
    ...
  }

could break.  We should check for that.

*** Generic tests for users to include

Matthew wrote some. Whether anyone else wants them remains to be seen.

The potentially useful ones:

**** test_SubsAllNeedTests

Checks all subs in a module are tested. Take the code and put it
somewhere else.

**** test_PodChecker

Look the sourcecode up in %INC and run it through the Pod::Checker
(which spits out stuff to STDOUT regardless).

**** test_HaveWarnings

Check $^W .. a bit cheeky. I was actually after a check for
strictness, after forgetting to use it in some module I broke off, but
this is either tricky or impossible.

[Impossible I believe. That's kind of the point of lexical scope after all
   -- pdc]

*** Test coverage tests

There was a big thread on this but it's someone else's turn to write
about that. 8-)  -- mca

Current thinking is to keep test-coverage tests away from the executed
tests, mainly so you can have a script which draws a pretty chart of
how well your code is tested. Adam has some code for this.

* Personal TODO lists

Moved here from doc/consensus.txt.

** Matthew

tktestrunner: ctrl-q, file menu shortcut

assert_deep_equals patches:
 check Test::More for updates
 can we do that direct use linkage?
 do I need to backport the patches we have?

move the scripts somewhere so they get installed in a bin/

put version numbers in all modules (my or our or oldestyle?)
as below,

 - if derived from CVS, with a note somewhere about bumping CVS
   versions if files take non-linear routes somewhere

 - cd src/Test-Unit; grep -rL VERSION lib/ | grep -v CVS/

*** integrate Debianisations and credit the relevant folks
/usr/share/doc/libtest-unit-perl/changelog.Debian.gz

note, dropped from Debian unstable:
  http://bugs.debian.org/279805
  http://bugs.debian.org/317416

*** update top-level README

*** Periodic checks
(should go in doc/release-checklist, or better yet in an installation
test)

Search for Test::* and check they still exist

Search for 'package' ... UnitHarness contains >1

http://www.cpan.org/modules/04pause.html says:
  Please make sure all your *.pm files contain a $VERSION variable that
  conforms to the CPAN rules, i.e. the complete computation of $VERSION
  must take place on the one first line within the module that assigns
  to it. You can test if this is the case by running

  perl -MExtUtils::MakeMaker -le 'print MM->parse_version(shift)' 'file'

*** Find a neat way to run unit-tested programs without the suite

It's convenient for medium sized projects to stick the test subs in
the classes they test, but then you have a run-time dependence on perlunit.

**** Local Variables:
**** mode: outline
**** End: