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.TestCa se
on small projects :)

Do others do their own "informal" unit testing?

Just curious,

Brad

[Chris Mellon]

On 10/4/07, brad <by*******@gmai l.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.TestCa se
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 <byte8b...@gmai l.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.TestCa se
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*******@gmai l.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********@yaho o.com wrote:

On Oct 4, 1:02 pm, brad <byte8b...@gmai l.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?

[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*******@gmai l.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.testfil e(). 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.TestCa se
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] nwrote:

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.testfil e(). 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.