Mercurial > pylearn

comparison doc/v2_planning/coding_style.txt @ 1132:f0a1b88367b0

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
coding_style: Looked into feasibility of forcing developers to test their code
author Olivier Delalleau <delallea@iro>
date Wed, 15 Sep 2010 14:02:45 -0400
parents aae62c4b2e9f
children 9baa47482ccc
comparison
equal deleted inserted replaced
1131:d9550c27a192 1132:f0a1b88367b0
267 covered by tests (see if we can get this from nosetests). Decorator to mark 267 covered by tests (see if we can get this from nosetests). Decorator to mark
268 some classes / methods as not being tested yet, so as to be able to 268 some classes / methods as not being tested yet, so as to be able to
269 automatically warn the user when he is using untested stuff (and to remind 269 automatically warn the user when he is using untested stuff (and to remind
270 ourselves we should add a test). 270 ourselves we should add a test).
271 Task: See feasibility. (OD) 271 Task: See feasibility. (OD)
272 Result: See section 'Enforcing strict testing policy'.
272 273
273 * VIM / Emacs plugins / config files 274 * VIM / Emacs plugins / config files
274 To enforce good coding style automatically. 275 To enforce good coding style automatically.
275 Task: Look for existing options. (FB) 276 Task: Look for existing options. (FB)
276 (DWF: I have put some time into this for vim, I will send around my files) 277 (DWF: I have put some time into this for vim, I will send around my files)
415 OD: Use numpy.inf and numpy.nan rather than float('inf') / float('nan')? 416 OD: Use numpy.inf and numpy.nan rather than float('inf') / float('nan')?
416 (should be slightly more efficient even if efficiency usually doesn't matter 417 (should be slightly more efficient even if efficiency usually doesn't matter
417 here - the main goal would be for everyone to use the same inf / nan to make 418 here - the main goal would be for everyone to use the same inf / nan to make
418 the code consistent). 419 the code consistent).
419 420
421 Enforcing strict testing policy
422 -------------------------------
423
424 The `coverage` third-party module provides a way to gather code coverage
425 statistics in the test suite. `nosetests` has a plugin that can be activated
426 with the --with-coverage option to use this module.
427 It is possible to know which lines specifically lack coverage. However, we
428 will probably want to post-process this data to do more than a simple report
429 (which noone will care about). This could be done either by parsing nosetests'
430 coverage output, or modifying its coverage plugin, or writing our own version
431 of it. The main goal would be to identify who is responsible for writing lines
432 that are not currently covered (using 'hg annotate'), in order to send email
433 notifications.
434
435 We should aim at 100% code coverage in tests. This is realistic because
436 `coverage` offers ways to ignore coverage for lines we explicitely do not want
437 to cover (typically debug code, or AssertionError / NotImplementedError that
438 are not supposed to be triggered during normal usage).
439 We may need to do some advanced processing though to e.g. collect results from
440 multiple build bots, if for instance some bot is running tests without GPU
441 support, and another one is taking care of the GPU tests.
442
443 Code that should be tested but for which no test is currently written would
444 also require some decorator / helper function that would trigger a warning at
445 run-time (only once / execution). This could be enforced by adopting a
446 different policy about lack-of-coverage notification emails, depending on
447 whether or not the warning is present:
448 - if there is no warning, daily email notification (ADD A WARNING!!!)
449 - if there is a warning, weekly email notification (ADD A TEST!!!)
450