unit testing

[brad]

Does anyone else feel that unittesting is too much work? Not in general,
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]

On 10/4/07, brad <by*******@gmail.comwrote:

Does anyone else feel that unittesting is too much work? Not in general,
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?

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.

[danmcleran]

On Oct 4, 1:02 pm, brad <[e-mail]:

Does anyone else feel that unittesting is too much work? Not in general,
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

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]

brad <by*******@gmail.comwrites:

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]

da********@yahoo.com wrote:

On Oct 4, 1:02 pm, brad <[e-mail]:

>Does anyone else feel that unittesting is too much work? Not in general,
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. =)

STeVe

[Bruno Desthuilliers]

Paul Rubin a écrit :

brad <by*******@gmail.comwrites:

>>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.

Or py.test or nose, which are both more complete than doctest and more
pythonics than the unittest module.

[Jeffrey Froman]

Chris Mellon wrote:

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]

On Behalf Of Bruno Desthuilliers

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]

On Oct 4, 2007, at 3:02 PM, brad 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?

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
--
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]

On 4 Okt., 22:49, Jeffrey Froman <[e-mail]:

Chris Mellon wrote:

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

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]

On Oct 3, 2:37 pm, Bruno Desthuilliers
<[e-mail]:

Paul Rubin a écrit :

brad <[e-mail]:

>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.

Or py.test or nose, which are both more complete than doctest and more
pythonics than the unittest module.

But you need to distribute testframeworks, when you just want to
distribute tests.

[Kay Schluehr]

On Oct 4, 9:39 pm, Paul Rubin <http://[e-mail]:

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

[byte8bits]

On Oct 5, 5:38 am, Craig Howard <[e-mail]:

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]

by*******@gmail.com wrote:

On Oct 5, 5:38 am, Craig Howard <[e-mail]:

>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.

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'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]

by*******@gmail.com wrote:

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]

On Oct 5, 4:12 pm, [e-mail] wrote:

On Oct 5, 5:38 am, Craig Howard <[e-mail]:

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

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-Effect.../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/resource...LegacyCode.pdf

Kay

[7stud]

What are some strategies for unit testing a function that obtains user
input?

Thanks.

[Paul Rubin]

7stud <bb**********@yahoo.comwrites:

What are some strategies for unit testing a function that obtains user
input?

For example: http://en.wikipedia.org/wiki/Expect

[=?iso-8859-1?q?Giampaolo_Rodol=E0?=]

On 3 Ott, 14:37, Bruno Desthuilliers
<[e-mail]:

Paul Rubin a écrit :

brad <[e-mail]:

>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.

Or py.test or nose, which are both more complete than doctest and more
pythonics than the unittest module.

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-pr...st-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]

by*******@gmail.com a écrit :
(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]

Giampaolo Rodolà <gn****@gmail.comwrites:

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]

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?

import py.test

py.test.raises(NameError, "blablabla")

--
http://www.advogato.org/person/eopadoan/
Bookmarks: http://del.icio.us/edcrypt

[Ben Finney]

7stud <bb**********@yahoo.comwrites:

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]

Paul Rubin <http://ph****@NOSPAM.invalidwrites:

Giampaolo RodolÃ* <gn****@gmail.comwrites:

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]

Ben Finney <bi****************@benfinney.id.auwrites:

Paul Rubin <http://ph****@NOSPAM.invalidwrites:

Giampaolo RodolÃ* <gn****@gmail.comwrites:

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]

Ben Finney <bi****************@benfinney.id.auwrites:

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]

On Oct 5, 4:51 pm, Ben Finney <[e-mail]>
wrote:

>

Thanks.

[Magnus Lycka]

by*******@gmail.com wrote:

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