3 ms·

Test Driven Development in Python

44 points by preek 15y ago

unshift 15y ago
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.
- pyre 15y ago
  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).
- tjr 15y ago
  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)!
- frankwiles 15y ago
  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 15y ago
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.
- khill 15y ago
  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 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/ 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.
- warp 15y ago
  I really like nose (http://somethingaboutorange.com/mrl/projects/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 15y ago
urschrei 15y ago
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/ 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/ http://diveintopython3.org/)
dqminh 15y ago
attest (http://packages.python.org/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.
chmike 15y ago
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.

44 points by preek 15y ago

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.

pyre 15y ago
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).
tjr 15y ago
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)!
frankwiles 15y ago
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 15y ago

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.

khill 15y ago
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 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/ 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.
warp 15y ago
I really like nose (http://somethingaboutorange.com/mrl/projects/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 15y ago

urschrei 15y ago

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/ 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/ http://diveintopython3.org/)

dqminh 15y ago

attest (http://packages.python.org/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.

chmike 15y ago

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.