

Test Driven Development in Python - preek
http://www.oreillynet.com/lpt/a/5463

======
unshift
is anybody really doing this in the real world? it seems kind of inefficient
to go through 15 testing cycles to write 10 lines of dead simple code.

i like to write tests before my code when i am trying to solve a specific
problem, or think of a new potential issue and want to test it, but i find
"pure" TDD takes it way too far. i don't see practical use in exhaustively
testing every single potential case for a simple wrapper around datetime. i do
like the idea for really critical sections, but it seems way overkill for most
code.

TDD to me seems, like most things, as a good tool to have in the tool box, but
moderation is key. articles like this are helpful to describe the practice but
tend to always prescribe it for everything.

~~~
frankwiles
Doing TDD isn't always about having 100% test coverage and as you described is
often wasted. But having coverage in line with how "important/complex" that
piece of code is wonderful, frees you to refactor more easily and saves you
from writing throw away test code, and/or manual testing.

Like most things in life, it's about moderation. Do you need 80+% test
coverage on your "tweet this" feature? No. Do you need 90+% test coverage of
your signup and ecommerce process flows? Absolutely!

Don't get hung up writing trivial tests as you described above, instead focus
on the things that really matter.

------
pyre
I'm actually interested in infrastructure around this. There is lots of
documentation about how to use the various unit testing libraries out there,
but what's the easiest way to _run_ all of your unit tests? In Perl, the
Makefile generated from Makefile.PL (or Build script generated from Build.PL)
has a 'test' command that will run tests that look like t/*.t (the pattern is
actually more permissive than this, but I'm not sure what the specs are beyond
that being the most common case). It will automatically setup the library
paths to include the code, etc, so that you don't have to manually fool around
with @INC (Perl's sys.path).

Is there something similar in setup.py? If so, how does it find which files
have tests to run?

edit: So there really isn't a standard Python way to 'run all unit tests?'
(I'm not counting v2.7 because Python unit tests have been around a lot longer
than that version has). I thought that Python was all about "there's only one
way to do it." I find it a little odd that it took so long for anything like
that to be included in the main distribution.

~~~
warp
I really like nose (<http://somethingaboutorange.com/mrl/projects/nose/>). You
can simply run "nosetests" in the root of your project, and it will locate and
run your tests.

nose will adjust sys.path to make sure your tests can find the packages
they're testing. This may depend a bit on the layout you're using for your
project, it has always worked for me so I have never had the need to look into
HOW it works :)

~~~
regularfry
I tend to find a bare "nosetests" catches a little more than I want it to, so
I generally specify at least a test directory.

------
urschrei
The linked article is seven years old. For more up-to-date Python TDD
techniques, see chapters 13 & 14 of Mark Pilgrim's 'Dive Into Python'
(available free at <http://diveintopython.org/>), and for Python 3 (though
plenty applies to Python 2) chapter 9 of 'Dive Into Python 3' (available free
at <http://diveintopython3.org/>)

------
chmike
TDD is very similare to define the use cases which make sense to di first. The
difference is that they are expressed in a very formal way that can be used as
validation test.

In such example, the benefit would be that a change in the date matching
algorithm could be done later and rely on the unit tests to detect a
regression.

------
dqminh
attest (<http://packages.python.org/Attest/>) is a really nice test framework
too. Feels much more natural to me than the usual setUp/tearDown pattern.

