unit testing

[Kay Schluehr]

Re: unit testing

On Oct 5, 4:12 pm, byte8b...@gmail .com wrote:

On Oct 5, 5:38 am, Craig Howard <craig.how...@e arthlink.netwro te:
>

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

Re: unit testing

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

Thanks.

[Paul Rubin]

Re: unit testing

7stud <bbxx789_05ss@y ahoo.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?=]

Re: unit testing

On 3 Ott, 14:37, Bruno Desthuilliers
<bdesth.quelque ch...@free.quel quepart.frwrote :

Paul Rubin a écrit :
>

brad <byte8b...@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.

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 "assertRais es"?
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]

Re: unit testing

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

Re: unit testing

Giampaolo Rodolà <gnewsg@gmail.c omwrites:

def test_answer():
assert 42 == 43
>
What's the equivalent of unittest's "assertRais es"?

def test_raises():
try:
thingy()
assert 42 == 43
except GoodException:
pass

[Eduardo O. Padoan]

Re: unit testing

What's the equivalent of unittest's "assertRais es"?

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]

Test doubles (stubs and mocks) for unit testing (was: unit testing)

7stud <bbxx789_05ss@y ahoo.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.co m/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.or g/wiki/PythonTestingTo olsTaxonomy>
<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?CouplingAn dCohesion>

--
\ "I'd take the awe of understanding over the awe of ignorance |
`\ any day." -- Douglas Adams |
_o__) |
Ben Finney

[Ben Finney]

Re: unit testing

Paul Rubin <http://phr.cx@NOSPAM.i nvalidwrites:

Giampaolo Rodolà <gnewsg@gmail.c omwrites:

def test_answer():
assert 42 == 43

What's the equivalent of unittest's "assertRais es"?

>
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.em acs |
Ben Finney

[Ben Finney]

Re: unit testing

Ben Finney <bignose+hate s-spam@benfinney. id.auwrites:

Paul Rubin <http://phr.cx@NOSPAM.i nvalidwrites:
>

Giampaolo Rodolà <gnewsg@gmail.c omwrites:

What's the equivalent of unittest's "assertRais es"?

def test_raises():
try:
thingy()
assert 42 == 43

>
Clearer would be:
>
assert False

Or even better:

def test_raises_goo d_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]

Re: unit testing

Ben Finney <bignose+hate s-spam@benfinney. id.auwrites:

Or even better:
>
def test_raises_goo d_exception():
try:
thingy()

Well if we're grading on style, maybe you really want to name the
function 'test_thingy' instead of 'test_raises_go od_exception'.

[7stud]

Re: Test doubles (stubs and mocks) for unit testing (was: unit testing)

On Oct 5, 4:51 pm, Ben Finney <bignose+hate s-s...@benfinney. id.au>
wrote:

>

Thanks.

[Magnus Lycka]

Re: unit testing

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