A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2001-February/012844.html below:

[Python-Dev] Unit testing (again)

[Python-Dev] Unit testing (again)Andrew Kuchling akuchlin@mems-exchange.org
Mon, 12 Feb 2001 22:52:23 -0500
On Mon, Feb 12, 2001 at 06:16:19PM -0500, Jeremy Hylton wrote:
>We can write a collection of helper functions for this, right?
>    self.verify(sequenceElementsThatSame(l1, l2))

Pretty much; nothing too difficult.

>Maybe I'd be less opposed if I could understand why it's desirable to
>continue executing a method where something has already failed
>unexpectedly.  After the first exception, something is broken and

In this style of unit test, you have setup() and shutdown() methods that
create and destroy the test objects afresh for each test case, so cases
aren't big long skeins of assertions that will all break given a single
failure.  Instead they're more like 1) call a method that changes an
object's state, 2) call accessors or get attributes to check invariants are
what you expect.  It can be useful to know that .get_parameter_value()
raises an exception while .get_parameter_type() doesn't, or whatever.

--amk



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4