Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #77001 > unrolled thread

Re: Switching from nose to unittest2 - how to continue after an error?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Switching from nose to unittest2 - how to continue after an error? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-25 21:12 +0100
    Re: Switching from nose to unittest2 - how to continue after an error? alex23 <wuwei23@gmail.com> - 2014-08-26 11:10 +1000

#77001 — Re: Switching from nose to unittest2 - how to continue after an error?

On 25/08/2014 20:54, Skip Montanaro wrote:
> On Mon, Aug 25, 2014 at 1:59 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> If you wish to write tests using something that can be compiled out please
>> don't let me stop you.  Having said that if nose or even nose2 works for you
>> why not stick with it?  There's also testfixtures, pytest, doctest and
>> presumably others.  Horses for courses?
>
> The test cases are run independently of the actual installed code
> base, so use of the assert statement is, at best, a minor issue. We
> don't use -O where I work either. Certainly, for me, the possibility
> that code might get compiled out was outweighed by its convenience.
>
> The nose folks say nose v1 will no longer be extended, that nose2 is
> the future. Alas, the API changed for plugins (which I'm currently
> trying unsuccessfully to get working). A couple questions to that list
> have so far gone unanswered (granted one of them was today), and
> before my questions, the latest thread with any replies was dated Aug
> 6. (That indicates to me that the nose group is pretty quiet.) Seeing
> that nose2 was mostly unittest2 and no longer having any <2.7
> constraint, I thought I would give it a try. Unfortunately, from my
> perspective it appears that the authors of that package mostly came up
> with a bunch of different spellings of "assert", requiring a bunch of
> tedious unit test changes for no obvious benefit. I realize that is
> almost certainly an unfair criticism, that there is more under the
> covers, but the lack of support for the assert statement is a problem
> for me.
>
> Skip
>

There's activity on this list if it helps gmane.comp.python.testing.general

I've also seen a reference to tox there.  Whatever happened to "There 
should be one-- and preferably only one --obvious way to do it."? :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [next] | [standalone]

#77013

On 26/08/2014 6:12 AM, Mark Lawrence wrote:
> Whatever happened to "There
> should be one-- and preferably only one --obvious way to do it."? :)

Ignoring for a moment that "one obvious way" only applies to 
Python-the-language, when it comes to libraries, there's a few factors 
(IMO) that affect this:

1. Some people find it easier to write something from scratch that read 
docs for an existing product.

2. It's easier to reimplement an existing concept than come up with 
something new.

This is actually a good thing, though, as monocultures die. Just chalk 
it up to evolutionary pressure :)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web