unit testing
brad
just the official unittest module for small to medium sized projects?
It seems easier to write some quick methods that are used when needed
rather than building a program with integrated unittesting. I see the
value of it (the official unittest that is)... especially when there's a
lot of source code. But this...
if len(x) != y:
sys.exit('...')
is a hell of a lot easier and quicker that subclassing unittest.TestCase
on small projects :)
Do others do their own "informal" unit testing?
Just curious,
Brad
Chris Mellon
Doctest is commonly given as the alternative to people who feel this
way. Personally, I find that anything worth testing is worth having a
test directory and independent unit tests for.
danmc...@yahoo.com
I actually do a lot of unit testing. I find it both annoying and
highly necessary and useful. I can't tell you how many bugs have been
squashed before ever leaving my cube by good unit testing. I also
agree that it can be a real pain. My opinion is you should do TDD
(test-driven development) and do it as much as you can tolerate. It
really will save you time and hassle in the long run.
Paul Rubin
> Does anyone else feel that unittesting is too much work? Not in
> general, just the official unittest module for small to medium sized
> projects?
Yeah, unittest is sort of a Java-ism. You might try the newer doctest
module instead.
Steven Bethard
> On Oct 4, 1:02 pm, brad <byte8b...@gmail.com> wrote:
>> Does anyone else feel that unittesting is too much work? Not in general,
>> just the official unittest module for small to medium sized projects?
> I actually do a lot of unit testing. I find it both annoying and
> highly necessary and useful.
+1 QOTW.
I feel exactly the same way. Writing tests (whether you use unittest,
doctest, py.test or whatever) is always a pain and a time sink. But
writing those tests catches so many bugs that it's worth it for any code
you expect to use more than twice. =)
STeVe
Bruno Desthuilliers
Or py.test or nose, which are both more complete than doctest and more
pythonics than the unittest module.
Tim Chase
>>> just the official unittest module for small to medium sized projects?
> [snip]
>> I actually do a lot of unit testing. I find it both annoying and
>> highly necessary and useful.
>
> +1 QOTW.
>
> I feel exactly the same way. Writing tests (whether you use unittest,
> doctest, py.test or whatever) is always a pain and a time sink. But
> writing those tests catches so many bugs that it's worth it for any code
> you expect to use more than twice. =)
If test-driven development doesn't appeal, you might prefer Titus
Brown's methodology from PyCon '07:
"""
I don't do test-driven development; I do stupidity-driven
testing. When I do something stupid, I write a test to make sure
I don't do it again.
"""
http://ivory.idyll.org/blog/feb-07/stupidity-driven-testing
-tkc
Jeffrey Froman
> Doctest is commonly given as the alternative to people who feel this
> way. Personally, I find that anything worth testing is worth having a
> test directory and independent unit tests for.
I like keeping my tests separate as well, and doctest does allow this, using
doctest.testfile(). That is, despite the name, doctests do not necessarily
need to appear in docstrings :-)
Jeffrey
Ryan Ginstrom
> Or py.test or nose, which are both more complete than doctest
> and more pythonics than the unittest module.
I second the recommendation of nose. It makes it fantastically easy to write
and run unit tests.
Also, in my experience unit tests help reduce bugs in the development
process, but their main benefits are making code more modular (writing for
testing tends to reduce dependencies) and easier to modify (less fear in
refactoring).
Regards,
Ryan Ginstrom
Craig Howard
> --
> http://mail.python.org/mailman/listinfo/python-list
Brad:
If the program is more than 100 lines or is a critical system, I
write a unit test. I hate asking myself, "Did I break something?"
every time I decide to refactor a small section of code. For
instance, I wrote an alarm system in Python for a water treatment
plant. If the chlorine, pH, or turbidity are out of spec, an email
message is sent to the plant operator's pager. Because of the nature
of the alarm system, extensive field testing was out of the question.
Unit testing was the only way to ensure it worked without disrupting
the plant operation.
Craig
Kay Schluehr
And they are definitely no unit tests. Instread they are diffs on
lexical content of an executed session protocol of arbitrary size
( which might be customized using a mini language ). So they are
sensitive to all kinds of ambient changes being irrelevant for the
*functional unit* to be tested.
I wish all people good luck porting their doctests to Python 3.0.
Kay Schluehr
But you need to distribute testframeworks, when you just want to
distribute tests.
Kay Schluehr
> Yeah, unittest is sort of a Java-ism.
However legend tells the story of Kent Beck and Erich Gamma sitting
together in a plane to ( or from ) New York and porting a unittest
framework from SmallTalk to Java. This extreme programming session was
the origin of JUnit.
It doesn't mean of course that XUnit is not a Javaism - it's just one
I like.
Kay
byte...@gmail.com
> Brad:
>
> If the program is more than 100 lines or is a critical system, I
> write a unit test. I hate asking myself, "Did I break something?"
> every time I decide to refactor a small section of code. For
> instance, I wrote an alarm system in Python for a water treatment
> plant. If the chlorine, pH, or turbidity are out of spec, an email
> message is sent to the plant operator's pager. Because of the nature
> of the alarm system, extensive field testing was out of the question.
> Unit testing was the only way to ensure it worked without disrupting
> the plant operation.
>
> Craig
Thanks to all for the opinions. Just to clarify, I have nothing
against testing. I like doing it. I catch a lot of bugs! I dislike the
formality of the unittest module. It's unyielding. It makes testing
difficult unless your code is written with testing in mind from the
start.
I maintain old code... code written a long time ago, before unittest
was popular. Getting unittest to work on that is difficult at best. So
we do informal testing ourselfs. The end result is the same... bugs
are squashed before the code is placed into production. Many times, we
find bugs as soon as we write a test!
Thanks again for the advice.
Brad
Steven Bethard
> On Oct 5, 5:38 am, Craig Howard <craig.how...@earthlink.net> wrote:
>> Brad:
>>
>> If the program is more than 100 lines or is a critical system, I
>> write a unit test. I hate asking myself, "Did I break something?"
>> every time I decide to refactor a small section of code. For
>> instance, I wrote an alarm system in Python for a water treatment
>> plant. If the chlorine, pH, or turbidity are out of spec, an email
>> message is sent to the plant operator's pager. Because of the nature
>> of the alarm system, extensive field testing was out of the question.
>> Unit testing was the only way to ensure it worked without disrupting
>> the plant operation.
>
> against testing. I like doing it. I catch a lot of bugs! I dislike the
> formality of the unittest module. It's unyielding. It makes testing
> difficult unless your code is written with testing in mind from the
> start.
There's been talk in the past about trying to bring some of the features
of py.test to the unittest module. However, I think there hasn't been
anyone with enough free time to start tackling this problem.
STeVe
Roy Smith
> Thanks to all for the opinions. Just to clarify, I have nothing
> against testing. I like doing it. I catch a lot of bugs! I dislike the
> formality of the unittest module. It's unyielding. It makes testing
> difficult unless your code is written with testing in mind from the
> start.
There is some advantage in forcing you to write code with testing in mind.
It often works out that the same things which make code easy to test (clean
interfaces, little cross-class dependency, etc), also make the code easy to
maintain and modify later.
Compared to some other testing frameworks I've used, unittest is pretty
lightweight. That's not to say that for small projects, even the small
amount of baggage it brings with it may feel heavy.
Kay Schluehr
Just one recommendation. I don't know your project and remote
diagnostics is usually more funny than usefull, but there is a body of
literature about dealing with legacy code, for example:
http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052
Of course Micheal Feathers talks constantly about putting systems
under test, exposing code for testability and lots more that goes
beyond code & fix.
Here is some article of the same author:
http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf
Kay
7stud
input?
Thanks.
Paul Rubin
> What are some strategies for unit testing a function that obtains user
> input?
For example: http://en.wikipedia.org/wiki/Expect
Giampaolo Rodolà
Very interesting, thank you.
This is the first time I heard about py.test so I took a look at what
it is:
http://codespeak.net/py/dist/test.html
http://ianbicking.org/docs/pytest-presentation/pytest-slides.html
At a first look it seems very comfortable to me but I noticed that all
usage examples shown uses nothing but the assert statement:
def test_answer():
assert 42 == 43
What's the equivalent of unittest's "assertRaises"?
In certain situations it is also useful to test wether an exception
(along its type) is raised or not.
Does py.test support such thing?
Bruno Desthuilliers
(snip)
>
> Thanks to all for the opinions. Just to clarify, I have nothing
> against testing. I like doing it. I catch a lot of bugs! I dislike the
> formality of the unittest module. It's unyielding. It makes testing
> difficult unless your code is written with testing in mind from the
> start.
Indeed. But that's not specific to the unittest module - you'd have the
same problem with any unit test framework.
Paul Rubin
> def test_answer():
> assert 42 == 43
>
> What's the equivalent of unittest's "assertRaises"?
def test_raises():
try:
thingy()
assert 42 == 43
except GoodException:
pass
Eduardo O. Padoan
> In certain situations it is also useful to test wether an exception
> (along its type) is raised or not.
> Does py.test support such thing?
import py.test
py.test.raises(NameError, "blablabla")
--
http://www.advogato.org/person/eopadoan/
Bookmarks: http://del.icio.us/edcrypt
Ben Finney
> What are some strategies for unit testing a function that obtains
> user input?
This is just one example of "how do I unit test a code unit that
interacts with something complex outside itself?" You want to test
*only* the code unit under test, not the external object with which it
interacts.
The answer is: Replace the external object irrelevant to your test
with a "test double" — a stub or mock object — that exhibits the
expected behaviour to the code unit, but doesn't perform the complex
behaviour that's irrelevant to your unit test.
If it's a matter of something simple and deterministic like "the input
for this test should be 'foo'", then the test double needs to do
nothing but respond to the expected method calls by producing the test
data. This is a "stub object", and you replace the real one with this
during the setup for your test case.
In more complex cases (e.g. "the code unit should write specific data
to this file", or "the code unit should make this change to the
database"), the test double needs to respond to method calls and
produce test data as needed, but also needs to be able to assert that
the right method calls were made. An instrumented test double like
this is called a "mock object", and you can query its state during the
test to assert that it has been manipulated as expected.
More about the difference between mock objects and stub objects:
<URL:http://martinfowler.com/articles/mocksArentStubs.html>
My favourite mock objects are created with Ian Bicking's "minimock",
which uses the doctest functionality for the instrumentation, and
keeps it really simple:
<URL:http://blog.ianbicking.org/minimock.html>
Set up any required test doubles at the start of each test case (so
you start with a known state each time), and switch back the real one
at the end of the test case. The test double thus becomes part of the
"test fixtures" for that specific test case.
More about test doubles (stub and mock objects) with Python:
<URL:http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy>
<URL:http://www.mockobjects.com/>
Note that this works best when the external interface is a replaceable
object, or a small number of them. If the number of things that need
to be replaced with test doubles just to perform a single test case is
high, that's a warning sign: your code unit is too tightly coupled to
too many things, and you need to refactor it soon to have a looser
interface to the rest of the system.
<URL:http://www.c2.com/cgi/wiki?CouplingAndCohesion>
--
\ "I'd take the awe of understanding over the awe of ignorance |
`\ any day." -- Douglas Adams |
_o__) |
Ben Finney
Ben Finney
> Giampaolo Rodolà <gne...@gmail.com> writes:
> > def test_answer():
> > assert 42 == 43
> >
> > What's the equivalent of unittest's "assertRaises"?
>
> def test_raises():
> try:
> thingy()
> assert 42 == 43
Clearer would be:
assert False
> except GoodException:
> pass
--
\ "Some people, when confronted with a problem, think 'I know, |
`\ I'll use regular expressions'. Now they have two problems." |
_o__) —Jamie Zawinski, in alt.religion.emacs |
Ben Finney
Ben Finney
> Paul Rubin <http://phr...@NOSPAM.invalid> writes:
>
> > Giampaolo Rodolà <gne...@gmail.com> writes:
> > > What's the equivalent of unittest's "assertRaises"?
> >
> > def test_raises():
> > try:
> > thingy()
> > assert 42 == 43
>
> Clearer would be:
>
> assert False
Or even better:
def test_raises_good_exception():
try:
thingy()
except GoodException:
pass
else:
raise AssertionError("Did not raise expected GoodException")
--
\ "Dad always thought laughter was the best medicine, which I |
`\ guess is why several of us died of tuberculosis." -- Jack |
_o__) Handey |
Ben Finney
Paul Rubin
> Or even better:
>
> def test_raises_good_exception():
> try:
> thingy()
Well if we're grading on style, maybe you really want to name the
function 'test_thingy' instead of 'test_raises_good_exception'.
7stud
Ben Finney
The function is a test case. It should be named for what specific case
it's testing.
A function named "test_thingy" (given the code unit is a function
named "thingy") would be some generic "do *all* the tests for
thingy". That's not a test case; perhaps it's the name of the unit
test module for "thingy".
--
\ "I must have a prodigious quantity of mind; it takes me as much |
`\ as a week sometimes to make it up." -- Mark Twain, _The |
_o__) Innocents Abroad_ |
Ben Finney
Magnus Lycka
> I maintain old code... code written a long time ago, before unittest
> was popular. Getting unittest to work on that is difficult at best.
Writing unit tests for lots of old code is not the most
funny thing you can imagine...
For situations like that, it might be much better to use
a tool like TextTest < http://texttest.carmen.se/ >.