pyunit-interest

[Pyunit-interest] How to test a condition

[Chuck E. <Chu...@ya...>]

The Py 2.1 docs direct the user to use self.failUnless() while the online 
docs at pyunit.sourceforge.net make it clear that using the assert 
statement is simple, easy and normal.

Since the latest pyunit was released post-Py 2.1, does this imply that Py 
2.2 will also lean towards the assert statement?

I'm curious: Are the docs for unittest at Python and at pyunit maintained 
separately?


-Chuck

[Pyunit-interest] [ANNOUNCE] PyUnit 1.4.1 released

[Steve P. <ste...@ya...>]

Version 1.4.1 of the PyUnit testing framework has just been released.

This is the inevitable minor bugfix release relative to Monday's 1.4
release.

Summary of changes since version 1.4:

 - fixed an incorrect code example in cookbook document
 - fixed bug when running 'unittest.py' from the command line in 
   order to execute tests in other modules (thanks to Gary Todd) *
 - corrected version number in distutils 'setup.py' (spotted by
   Jerome Marant)

The release is available from the PyUnit homepage at

  http://pyunit.sourceforge.net/

Very best wishes to all,

-Steve

* This bug is also fixed in the Python CVS tree.

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Fingerprint: EB79 2AB1 D494 16F9 8C3B  DAC6 5341 30CE BCCA EBEA

[Pyunit-interest] [ANNOUNCE] PyUnit 1.4 released

[Steve P. <ste...@ya...>]

Version 1.4 of the PyUnit testing framework has just been released.

The primary intention of this release is to provide a standalone package of
the same PyUnit code contained in the Python 2.1 standard library. This is
primarily for the benefit of those who use older (or Java-flavoured)
versions of Python.

The release may also be of interest to Python 2.1 users who would like to
run their tests using the Tkinter-based GUI test runner tool which is part
of the PyUnit package but is not contained in the Python standard library.

Summary of changes since version 1.3.1:

  - Updated documentation
  - main() runs all tests in the module __main__ by default
  - New code allows all test cases in a given module to be located and
    instantiated
  - Simplified command line syntax
  - Made TextTestRunner configurable with verbose and quiet options, and
    consequently removed obsoleted JUnitTextTestRunner
  - Test instantiation code now localised in a replaceable TestLoader class
  - Distutils 'setup.py' contributed by Bill Bumgarner
  - TestResult.addSuccess() method added (thanks to Frederic Corne)
  - Stop overridden test methods being run twice (thanks to Brian Zimmer
    and Maas-Marten Zeeman)
  - Don't expand GUI's progress bar vertically when resizing (Fred Drake)

The release is available from the PyUnit homepage at

  http://pyunit.sourceforge.net/

or directly from

  http://prdownloads.sourceforge.net/pyunit/pyunit-1.4.0.tar.gz

Very best wishes to all,

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Test your web apps with http://webunit.sourceforge.net/

Re: [Pyunit-interest] unittest.py patch

[Fred L. D. Jr. <fd...@ac...>]

Steve Purcell writes:
 > And lo! - neither was checked in. I'll make a change along these
 > lines, then.

  Either option would be better than the current non-message; please
make the change on the trunk of the Python sources as well.
  Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations

Re: [Pyunit-interest] unittest.py patch

[Steve P. <ste...@ya...>]

Fred L. Drake, Jr. wrote:
> 
>   I'd like to suggest the attached patch to unittest.py.
>   When running a test that fails to raise an expected exception (using
> assertRaises()), the message is just the name of the exception, not
> something that says the exception was expected but failed to occur.
> The attached patch fixes this.


Hi Fred,

Well, that's the way it used to be! Then, prior to the Python 2.1 release,
I received a proposed patch from Jeremy Hylton, which I applied in modified
form to get the current message; the patch aimed to fix a perceived problem
of clarity.

I was happy with the more terse message, but others obviously weren't. In
the light of the varied opinions on the matter, I suggest we keep the
message as it is rather than change it again.

-Steve


-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Test your web apps with http://webunit.sourceforge.net/

Re: [Pyunit-interest] Argument passing question

[Steve P. <ste...@ya...>]

Hello Russell,

Sorry for the delay in responding to your posting.

Russell Shotts wrote:
> I am evaluating PyUnit for a testing framework I need at work.  I'm running
> into one small problem.  One of our requirements is to execute each test
> once for each file in a rather large set of input files.  Ideally, I need a
> mechanism to iterate over the files in the file set, and execute each test
> suite once (and subsequently, each test case within the suite) once for the
> given file.  I don't see any real hooks to pass arguments to the test suite
> or test case.


If the results of all the tests are expected to be the same for every possible
set of input files, then the input files really constitute an 'environment'
in which you run your suite of tests. (If different results were expected
for different input files, then each test/file combination would be a
distinct TestCase.)

The simplest solution would be to write a module which provides
a configurable singleton environment object. In your case, the environment
object would represent a group of input files.

    #--- my_test_environment.py
    class Environment:
        def __init__(self, input_file1, input_file2):
            self.input_file1 = input_file1
            self.input_file2 = input_file2

    environment = None

    def initialise(*args, **kwargs):
        global environment
        environment = apply(Environment, args, kwargs)

    # set a default environment
    initialise('./data/file1', './data/file2')


Then, you make your tests access the names of the files they should open via
the Environment object 'my_test_environment.environment'.

You can run all your tests against the default set of files without changing
any further code.

To run the tests against all your different sets of files, you can alter
the environment object before running tests:

    my_test_environment.initialise('./other_data/file1', './other_data/file2')
    load_and_run_all_tests()  # with TestLoader/TextTestRunner, for example
    my_test_environment.initialise('./more_data/file1', './more_data/file2')
    load_and_run_all_tests()

You can obviously automate this process of looping over input file sets.

Does that help?

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Test your web apps with http://webunit.sourceforge.net/

Re: [Pyunit-interest] unittest.py patch

[Steve P. <ste...@ya...>]

Fred L. Drake, Jr. wrote:
>   Interesting!  I find the current (lack of) a message to be
> completely unclear, and am a little surprised that Jeremy thought it
> better than something that said what went wrong.


Hang on... sorry... I'm talking out of my hat, and misrepresenting Jeremy.
Jeremy suggested:

    "Expected call to raise %s"

On the fuzzy grounds of greater language neutrality I counter-proposed:

    "%s not raised"

And lo! - neither was checked in. I'll make a change along these lines, then.

>   I can live with this, but am mystified that anyone thinks the
> current message is better.

I'm mystified that I thought the current message was not the current message...

:-)

-Steve


-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Test your web apps with http://webunit.sourceforge.net/

Re: [Pyunit-interest] unittest.py patch

[Fred L. D. Jr. <fd...@ac...>]

Steve Purcell writes:
 > Well, that's the way it used to be! Then, prior to the Python 2.1 release,
 > I received a proposed patch from Jeremy Hylton, which I applied in modified
 > form to get the current message; the patch aimed to fix a perceived problem
 > of clarity.

  Interesting!  I find the current (lack of) a message to be
completely unclear, and am a little surprised that Jeremy thought it
better than something that said what went wrong.

 > I was happy with the more terse message, but others obviously weren't. In
 > the light of the varied opinions on the matter, I suggest we keep the
 > message as it is rather than change it again.

  I can live with this, but am mystified that anyone thinks the
current message is better.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations

[Pyunit-interest] unittest.py patch

[Fred L. D. Jr. <fd...@ac...>]

  I'd like to suggest the attached patch to unittest.py.
  When running a test that fails to raise an expected exception (using
assertRaises()), the message is just the name of the exception, not
something that says the exception was expected but failed to occur.
The attached patch fixes this.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations

[Pyunit-interest] Argument passing question

[Russell S. <ras...@mn...>]

Hi,

I am evaluating PyUnit for a testing framework I need at work.  I'm running
into one small problem.  One of our requirements is to execute each test
once for each file in a rather large set of input files.  Ideally, I need a
mechanism to iterate over the files in the file set, and execute each test
suite once (and subsequently, each test case within the suite) once for the
given file.  I don't see any real hooks to pass arguments to the test suite
or test case.

My initial hopes were dashed when I found that both TestSuite.Run() and
TextTestRunner.Run() both directly call the test rather than calling a an
overridable method to do so.  That would have given me a perfect hook to
push one or more values into the target before executing it.

Can I do this via some trickery with a customized TestLoader?  How have
others approached this problem?  I hope the answer is not to code a unique
test case for each combination of test case and input file - the size (as
well as the subsequent effort to maintain and extend) would be overwhelming.

Thanks in advance.

Russ

RE: [Pyunit-interest] comments on PyUnit

[Patrick K. O'B. <po...@or...>]

See my responses mixed in below.

Graham Hughes wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "Patrick K. O'Brien" <po...@or...> writes:
>
> > Were you honestly able to maintain a straight face while you
> wrote this? Why
> > would we write tests that we expected to fail? We expect all
> the tests to
> > succeed, unless the code is wrong. That is the whole premise
> behind the unit
> > testing framework. Take a look at these method descriptions taken from
> > http://www.python.org/doc/current/lib/testcase-objects.html and
> try to think
> > of a good name for each method:
>
> On the contrary, often I test that things fail in the correct manner:
> for example, `assert not cgi.isValid ()' from my validation suite.
> `self.failIf (cgi.isValid ())' would be a considerable improvement,
> but in a different test `self._assert (cgi.isValid ())' is just fine.
> If anything is to be removed I would argue assert* and fail* methods
> with the word `not' in them should die, because it makes the logic
> even more circuitous than necessary.  But I don't use them and I don't
> particularly begrudge others the use of them.

I agree that the "Not" versions are the most difficult.

>
> >     Test that first and second are equal. (sounds like testEqual to me)
> >
> >     Test that first and second are not equal. (sounds like
> testNotEqual to
> > me)
> >
> >     Test that an exception is raised. (sounds like testException or
> > testRaises to me)
>
> Having worked with PyUnit for quite some time now, I cannot agree.
> testEqual communicates nothing; am I testing whether they *are* equal?
> You say the answer is obviously yes, but test alone is an empty verb.
> `Test', in the absence of context, means `to subject to a test', and
> connotes nothing about the direction of the desired result!

This is not "test" in the absence of context, this is "test" in the context
of the unit testing framework. In this context it is synonymous with
"assert" with the understanding that "assert" was to be
avoided/deprecated/only-maintained-for-legacy-purposes. I'm sure that anyone
who uses a given convention for a period of time grows used to that
convention to the point that it seems quite normal. I am looking at this
situation from the viewpoint of someone new to unittest and possibly also
new to Python. The existing names do not strike me as a model of clarity. I
agree that "assert" is better than "test" but I thought the point was to
eliminate "assert" to the degree possible. However, there doesn't seem to
even be consensus on that matter, which is confusing me even more. Maybe I
am alone in my confusion, but I kinda doubt that.

>
> The assert* and fail* are much better for this.  If you know what the
> word assert means, it is very easy to see which direction assertEqual
> and failIfEqual go.  testEqual isn't even good English--it should be
> testEquality at the very least, and then testInequality--and is silent
> regardless on whether the test should succeed or fail.
>

Assert is fine if I knew that it wasn't to be avoided. If it wasn't to be
avoided why did the fail synonyms get added? I have a real mental block with
the fail* names, but maybe that's just me. I'm sure given time I could learn
to love them.

Sure testEqual is bad English, but when has that ever been an issue in a
programming language? <wink> Seriously, we abreviate things all the time -
str() returns a string version of whatever is passed to it - that's
intuitive? No, but it isn't a huge leap either. If I wanted to be
grammatical then I agree it should be testForEqualityOtherwiseRaiseException
or something. But again, it isn't a huge leap to abbreviate that to
testEqual. I don't think much is lost, you type less, and it still fits my
thought process.

> You assert that it is obvious that the test should succeed because you
> assert that all tests must succeed, but the logic in this is
> unconvincing to me.

I don't think this is *my* logic but the logic of the unit testing framework
approach. Either that or I'm missing the boat. I thought the idea was to
write tests that ultimately succeed once the code being tested does what it
is supposed to do. And if a future change to the code breaks something, the
test will now fail. Then the code will need to be fixed. Working code has a
test suite of tests that all succeed. Now the test may define success as
"failing gracefully by raising the proper exception" but the test still
succeeds. I think this is the mental block I have with the fail* versions -
they seem to imply failure when I am thinking success.

>
> > I can't think of any word that is less ambiguous in this
> context. Who cares
> > what action is to be taken? We just want to test certain conditions and
> > raise a red flag if anything breaks. Some of those conditions
> happen to fit
> > into a common pattern so we have specific methods for those - we want to
> > test for equality, inequality and the raising of exceptions.
> Then we have a
> > blanket test that allows the user to define their own
> condition. Finally, we
> > want to test for the inverse of some condition.
>
> I care what action is to be taken.  I want it to be obvious that the
> test will *fail* if the two arguments are equal, that the test will
> *fail* if the exception is not raised.
>

Maybe this is the root of our disagreement. I want the test to succeed. You
want it to fail. Maybe it is just semantics. Maybe there are just as many
people who fall into both camps. Maybe the same person wants it one way in
one context and the other way in another context.

Thank you for your thoughts on this matter.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

[Pyunit-interest] Name discussions

[Kevin B. <kb...@ca...>]

Any name that is chosen is likely to be ambiguous - I've personally had to teach
several people that "assert" means "I expect it this way and want you to fail if my
assertion is false", and had to convince one engineer to go back and switch every one
of the methods in his newly crafted C++ assertion library...

I personally use assert* because it is standard across many platforms, and find "test
is a synonym for assert" quite acceptable.

kb

-----Original Message-----

> From: pyu...@li...
> [mailto:pyu...@li...]On Behalf Of Gareth Rees
> Sent: Tuesday, July 03, 2001 1:52 PM
> To: po...@or...
> Cc: Pyunit-Interest
> Subject: RE: [Pyunit-interest] comments on PyUnit
>
> At 10:54 -0500 2001-07-03, Patrick K. O'Brien wrote:
> >Okay, here is a proposal. And I know I am coming up with this rather late
> in
> >the game, for which I apologize.
> >
> >The magic word is "test." And the new method names are:
>
> "Test" is a poor name in this context, because the name "test"
> doesn't indicate clearly whether the thing to be tested is expected
> to succeed or fail, nor what action is to be taken once the test is
> completed.

RE: [Pyunit-interest] comments on PyUnit

[Fred L. D. Jr. <fd...@ac...>]

Patrick K. O'Brien writes:
 > Here's a question for everyone who thinks this should be put to rest - Do we
 > want Python programmers to actually use this module? Do we want it to be

  The answer is yes; if we didn't want that, it wouldn't have been
added to the standard library.

 > used only by the experts who fully understand both Python and unit testing
 > frameworks in other languages? Or do we also want it to be as usable to
 > beginning programmers who have only used Python and don't know the entire
 > history of the framework?

  I think the documentation does not assume specific knowledge of the
other xUnit frameworks, and is a good reference manual for the
module.  If you found specific problems with the documentation, or
have suggestions for improvement, please submit a bug report (which
can be a documentation bug or feature request) at SourceForge:

	http://sourceforge.net/projects/python

If you mark the report "Documentation" it will be assigned to me
automatically.
  My experience with the PyUnit is that I am now more likely to write
better tests sooner than I used to be.  Part of that reflects the
growth of my experience as a developer, and part of that comes from
the ready availability of a usable framework.
  Does that mean it isn't possible to improve PyUnit?  No.  But making
changes to the published API would not be an improvement, and would
make the Python community less likely to adopt it because the API
would be perceived as a moving target.  The result would be a delay in
the creation of unit tests and more ad hoc frameworks that constantly
need revision (such as the test.regrtest module that runs the Python
standard library's unit/regression tests).  That only slows the
adoption of good testing practices.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations

RE: [Pyunit-interest] comments on PyUnit

[Patrick K. O'B. <po...@or...>]

The fuss, for me, is that I see this as a barrier to entry for those who
want to practice good programming techniques. I experienced this myself when
I first looked at unittest. I found the names themselves, and the multitude
of names, confusing and unsettling. It has made it that much harder to make
use of an otherwise excellent addition to Python. So I think it is worth the
effort and agony to try to simplify things. Simplicity and coherence is
certainly one of the big appeals of Python and I would like to see that
extend to unittest.

Here's a question for everyone who thinks this should be put to rest - Do we
want Python programmers to actually use this module? Do we want it to be
used only by the experts who fully understand both Python and unit testing
frameworks in other languages? Or do we also want it to be as usable to
beginning programmers who have only used Python and don't know the entire
history of the framework?

I think the goal should be to make unit tests as ubiquitous as the code that
it is testing.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: pyu...@li...
[mailto:pyu...@li...]On Behalf Of Steve
Purcell
Sent: Wednesday, July 04, 2001 7:43 AM
To: John J. Lee
Cc: Pyunit-Interest
Subject: Re: [Pyunit-interest] comments on PyUnit

John J. Lee wrote:
> Come on, Steve, this whole discussion was about what should be the
> *standard* names.  We all know you can rename things!


What's the fuss? There's already a *standard* set of methods, and a
*standard*
set of names for them, some of which are synonyms. All of those are
documented
in the standard library docs. People may pick whichever synonyms they like,
or invent their own.

None of the synonyms for a given method is 'preferred' or 'more standard'
than
another. All are absolutely standard, supported and in widespread use as of
PyUnit's bundling with Python >= 2.1, which also largely freezes the module
API.

-Steve

--
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Any opinions expressed herein are my own and not necessarily those of Yahoo

_______________________________________________
Pyunit-interest mailing list
Pyu...@li...
http://lists.sourceforge.net/lists/listinfo/pyunit-interest

Re: [Pyunit-interest] comments on PyUnit

[Steve P. <ste...@ya...>]

John J. Lee wrote:
> Come on, Steve, this whole discussion was about what should be the
> *standard* names.  We all know you can rename things!


What's the fuss? There's already a *standard* set of methods, and a *standard*
set of names for them, some of which are synonyms. All of those are documented
in the standard library docs. People may pick whichever synonyms they like,
or invent their own.

None of the synonyms for a given method is 'preferred' or 'more standard' than
another. All are absolutely standard, supported and in widespread use as of
PyUnit's bundling with Python >= 2.1, which also largely freezes the module
API.

-Steve

-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Any opinions expressed herein are my own and not necessarily those of Yahoo

Re: [Pyunit-interest] comments on PyUnit

[Fred L. D. Jr. <fd...@ac...>]

John J. Lee writes:
 > -'assert' (both the keyword and as part of a function name) should be
 > deprecated for unit-testing purposes, for the reasons he pointed out

  The catch, of course, is that the assert*() names were already in
fairly widespread use, so cannot reasonably be deprecated.  In light
of that, it makes more sense to simply allow any of the names and not
worry about it further.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations

RE: [Pyunit-interest] comments on PyUnit

[Gareth R. <gd...@ra...>]

At 17:17 -0500 2001-07-03, Patrick K. O'Brien wrote:
>Were you honestly able to maintain a straight face while you wrote this?

I can assure you that I was quite sincere.

Re: [Pyunit-interest] comments on PyUnit

[John J. L. <ph...@cs...>]

On Wed, 4 Jul 2001, Steve Purcell wrote:

> Patrick K. O'Brien wrote:
> > <getting on soapbox>
> >
> > Frankly, the existing names seem like a horrific attempt to avoid the word
> > "test." Reminds me of the story of the blind men trying to describe an
> > elephant. Now that we can see the beast, let's just call it an elephant.
> >
> > <off soapbox>
>
>
> If they bother you so much, why not try
>
>     class BasicTestCase(unittest.TestCase):
>         testEqual = unittest.TestCase.assertEqual
>         # ... etc ...
>
> and use this as the base class for your tests instead of unittest.TestCase.

Come on, Steve, this whole discussion was about what should be the
*standard* names.  We all know you can rename things!

I take the point that there are already many 'standard-ish' (ie.
defined in pyunit) names, and it would be a bad thing, in itself, to add
more.  However (and correct me if I don't remember the outcome of the
discussion right), I thought that Guido had indicated that

-'assert' (both the keyword and as part of a function name) should be
deprecated for unit-testing purposes, for the reasons he pointed out

-the standard names should not force you to use double negatives

I don't remember whether, in the end, we ended up with a set of function
names that follow these rules, and that are already in pyunit.  So, are
they there, and if not, isn't it worth adding them?


John

Re: [Pyunit-interest] comments on PyUnit

[Steve P. <ste...@ya...>]

Patrick K. O'Brien wrote:
> <getting on soapbox>
> 
> Frankly, the existing names seem like a horrific attempt to avoid the word
> "test." Reminds me of the story of the blind men trying to describe an
> elephant. Now that we can see the beast, let's just call it an elephant.
> 
> <off soapbox>


If they bother you so much, why not try

    class BasicTestCase(unittest.TestCase):
        testEqual = unittest.TestCase.assertEqual
        # ... etc ...

and use this as the base class for your tests instead of unittest.TestCase.

-Steve


-- 
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Any opinions expressed herein are my own and not necessarily those of Yahoo

Re: [Pyunit-interest] comments on PyUnit

[Graham H. <gr...@ly...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Patrick K. O'Brien" <po...@or...> writes:

> Were you honestly able to maintain a straight face while you wrote this? Why
> would we write tests that we expected to fail? We expect all the tests to
> succeed, unless the code is wrong. That is the whole premise behind the unit
> testing framework. Take a look at these method descriptions taken from
> http://www.python.org/doc/current/lib/testcase-objects.html and try to think
> of a good name for each method:

On the contrary, often I test that things fail in the correct manner:
for example, `assert not cgi.isValid ()' from my validation suite.
`self.failIf (cgi.isValid ())' would be a considerable improvement,
but in a different test `self._assert (cgi.isValid ())' is just fine.
If anything is to be removed I would argue assert* and fail* methods
with the word `not' in them should die, because it makes the logic
even more circuitous than necessary.  But I don't use them and I don't
particularly begrudge others the use of them.

>     Test that first and second are equal. (sounds like testEqual to me)
> 
>     Test that first and second are not equal. (sounds like testNotEqual to
> me)
> 
>     Test that an exception is raised. (sounds like testException or
> testRaises to me)

Having worked with PyUnit for quite some time now, I cannot agree.
testEqual communicates nothing; am I testing whether they *are* equal?
You say the answer is obviously yes, but test alone is an empty verb.
`Test', in the absence of context, means `to subject to a test', and
connotes nothing about the direction of the desired result!

The assert* and fail* are much better for this.  If you know what the
word assert means, it is very easy to see which direction assertEqual
and failIfEqual go.  testEqual isn't even good English--it should be
testEquality at the very least, and then testInequality--and is silent
regardless on whether the test should succeed or fail.

You assert that it is obvious that the test should succeed because you
assert that all tests must succeed, but the logic in this is
unconvincing to me.

> I can't think of any word that is less ambiguous in this context. Who cares
> what action is to be taken? We just want to test certain conditions and
> raise a red flag if anything breaks. Some of those conditions happen to fit
> into a common pattern so we have specific methods for those - we want to
> test for equality, inequality and the raising of exceptions. Then we have a
> blanket test that allows the user to define their own condition. Finally, we
> want to test for the inverse of some condition.

I care what action is to be taken.  I want it to be obvious that the
test will *fail* if the two arguments are equal, that the test will
*fail* if the exception is not raised.

<snip rest>
- -- 
Graham Hughes <gr...@ly...>
PGP fingerprint: 1F1D 0027 B835 E114 3F5B  2C7C 64D1 83A0 C5C7 312A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard <http://www.gnupg.org/>

iD8DBQE7QnGlZNGDoMXHMSoRAnzrAKDH+ngj5Sr9W1hP+und6PQ2BgH/AwCgqAEb
GQYz3/9411CQ/6+tPxzFK0s=
=xm5Y
-----END PGP SIGNATURE-----

RE: [Pyunit-interest] comments on PyUnit

[Patrick K. O'B. <po...@or...>]

<getting on soapbox>

Were you honestly able to maintain a straight face while you wrote this? Why
would we write tests that we expected to fail? We expect all the tests to
succeed, unless the code is wrong. That is the whole premise behind the unit
testing framework. Take a look at these method descriptions taken from
http://www.python.org/doc/current/lib/testcase-objects.html and try to think
of a good name for each method:

    Test that first and second are equal. (sounds like testEqual to me)

    Test that first and second are not equal. (sounds like testNotEqual to
me)

    Test that an exception is raised. (sounds like testException or
testRaises to me)

I can't think of any word that is less ambiguous in this context. Who cares
what action is to be taken? We just want to test certain conditions and
raise a red flag if anything breaks. Some of those conditions happen to fit
into a common pattern so we have specific methods for those - we want to
test for equality, inequality and the raising of exceptions. Then we have a
blanket test that allows the user to define their own condition. Finally, we
want to test for the inverse of some condition.

Frankly, the existing names seem like a horrific attempt to avoid the word
"test." Reminds me of the story of the blind men trying to describe an
elephant. Now that we can see the beast, let's just call it an elephant.

The more I think about this the more convinced I am about my position.
Unless someone can show how assert* or fail* do a better job to "indicate
clearly whether the thing to be tested is expected to succeed or fail" and
"what action is to be taken once the test is completed."

<off soapbox>

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: pyu...@li...
[mailto:pyu...@li...]On Behalf Of Gareth Rees
Sent: Tuesday, July 03, 2001 1:52 PM
To: po...@or...
Cc: Pyunit-Interest
Subject: RE: [Pyunit-interest] comments on PyUnit

At 10:54 -0500 2001-07-03, Patrick K. O'Brien wrote:
>Okay, here is a proposal. And I know I am coming up with this rather late
in
>the game, for which I apologize.
>
>The magic word is "test." And the new method names are:

"Test" is a poor name in this context, because the name "test"
doesn't indicate clearly whether the thing to be tested is expected
to succeed or fail, nor what action is to be taken once the test is
completed.

_______________________________________________
Pyunit-interest mailing list
Pyu...@li...
http://lists.sourceforge.net/lists/listinfo/pyunit-interest

RE: [Pyunit-interest] comments on PyUnit

[Gareth R. <gd...@ra...>]

At 10:54 -0500 2001-07-03, Patrick K. O'Brien wrote:
>Okay, here is a proposal. And I know I am coming up with this rather late in
>the game, for which I apologize.
>
>The magic word is "test." And the new method names are:

"Test" is a poor name in this context, because the name "test" 
doesn't indicate clearly whether the thing to be tested is expected 
to succeed or fail, nor what action is to be taken once the test is 
completed.

RE: [Pyunit-interest] comments on PyUnit

[John J. L. <ph...@cs...>]

On Tue, 3 Jul 2001, Patrick K. O'Brien wrote:

> Okay, here is a proposal. And I know I am coming up with this rather late in
> the game, for which I apologize.
>
> The magic word is "test." And the new method names are:
[...]

I'd vote for that.


John

RE: [Pyunit-interest] comments on PyUnit

[Patrick K. O'B. <po...@or...>]

Okay, here is a proposal. And I know I am coming up with this rather late in
the game, for which I apologize.

The magic word is "test." And the new method names are:

test = assert_ = failUnless

testEqual = assertEqual = assertEquals = failUnlessEqual

testNotEqual = assertNotEqual = assertNotEquals = failIfEqual

testRaises = assertRaises = failUnlessRaises

testNot = failIf

fail (unchanged)

Call me crazy, but this fits my brain a lot better than the existing method
names. Any problems with this?

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: pyu...@li...
[mailto:pyu...@li...]On Behalf Of Guido van
Rossum
Sent: Tuesday, July 03, 2001 10:21 AM
To: po...@or...
Cc: Pyunit-Interest; Guido van Rossum
Subject: Re: [Pyunit-interest] comments on PyUnit

Don't look at me to break this tie!  I haven't bee paying enough
attention to be of much help.  Make a proposal.

Some of the forces that go into this:

- Using "assert" sends the wrong message because it suggests an
  equivalence with assert statements, but those are disabled under
  certain compilation options (ditto for the choice to raise
  AssertionError).

- But for some of the functions, noone came up with a reasonable name
  that doesn't use "assert".

--Guido van Rossum (home page: http://www.python.org/~guido/)

RE: [Pyunit-interest] comments on PyUnit

[Patrick K. O'B. <po...@or...>]

"test"

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: pyu...@li...
[mailto:pyu...@li...]On Behalf Of Michal
Wallace
Sent: Tuesday, July 03, 2001 11:41 AM
To: Pyunit-Interest
Subject: Re: [Pyunit-interest] comments on PyUnit

On Tue, 3 Jul 2001, Guido van Rossum wrote:

> - But for some of the functions, noone came up with a reasonable name
>   that doesn't use "assert".

"expect"?

Cheers,

- Michal
------------------------------------------------------------------------
www.manifestation.com  www.sabren.net  www.linkwatcher.com  www.zike.net
------------------------------------------------------------------------


_______________________________________________
Pyunit-interest mailing list
Pyu...@li...
http://lists.sourceforge.net/lists/listinfo/pyunit-interest