Test Driven Development in Python | Hacker News Reader

Test Driven Development in Python

oreillynet.com

44 pointspreek11 comments

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.

It depends on your use-case. If you exhaustively test something that is a simple wrapper around datetime, then you could swap out datetime with something else and still be reasonably confident that it still works (I realize that this is less likely in this example).

I worked on a project where we did lots of unit tests along these lines. It was for an avionics networking library, where assurance of robustness is more called for than with, say, most web applications.

And in general, avionics software development does feel both very inefficient and (mostly) very simple. But our customers are very happy when it doesn't crash (figuratively or literally)!

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.

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.

Starting in 2.7, the unittest module actually has the ability to discover tests so you can just do:

python -m unittest discover

The docs are here:

http://docs.python.org/library/unittest.html#test-discovery

I've actually been using both unittest and pytest for a while - I like pytest better but they are both nice tools.

http://doc.pytest.org/en/latest/

I found Tarek Ziade's book useful when learning how to best set up and execute unit tests as part of my python projects.

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 :)

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.

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/)

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.

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.

Reply on news.ycombinator.com