Re: unittest vs py.test?

<[EMAIL PROTECTED]> wrote: >py.test is awesome, but there is one slight flaw in it. It produces to >much output. All I want to see when all tests pass is "All X passes >succeded!" (or something similar). py.test's output can be >distracting. I agree. -- http://mail.python.org/mailman/listinfo/pyt

Re: unittest vs py.test?

py.test is awesome, but there is one slight flaw in it. It produces to much output. All I want to see when all tests pass is "All X passes succeded!" (or something similar). py.test's output can be distracting. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list

Re: unittest vs py.test?

On Tue, 5 Apr 2005 14:02:49 GMT, Michael Hudson <[EMAIL PROTECTED]> wrote: >Roy Smith <[EMAIL PROTECTED]> writes: > >> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bengt Richter) >> > Is there a package that is accessible without svn? >> >> That seems to be its weak point right now. >> >>

Re: unittest vs py.test?

Michael Hudson wrote: Peter Hansen <[EMAIL PROTECTED]> writes: Where was all that weight that unittest supposedly has? For PyPy we wanted to do some things that the designers of unittest obviously hadn't expected[1], such as formatting tracebacks differently. This was pretty tedious to do[2], I'd

Re: unittest vs py.test?

Peter Hansen <[EMAIL PROTECTED]> writes: > Raymond Hettinger wrote: > > [Peter Hansen] > > > >>This is pretty, but I *want* my tests to be contained > >>in separate functions or methods. > > In py.test, those would read: > > def test1(): > > assert a == b > > def test2(): > > raises(Error

Re: unittest vs py.test?

Roy Smith <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bengt Richter) > > Is there a package that is accessible without svn? > > That seems to be its weak point right now. > > Fortunately, you can get pre-built svn clients for many platforms > (http://subver

Re: unittest vs py.test?

In article <[EMAIL PROTECTED]>, Jeremy Bowers <[EMAIL PROTECTED]> wrote: > On Mon, 04 Apr 2005 22:50:35 +, John J. Lee wrote: > > What I don't understand about py.test (and trying it out seems > > unlikely to answer this) is why it uses the assert statement. > > unittest used to do that, too,

Re: unittest vs py.test?

py.test intercepts the assert statements before they are optimized away. It's part of the profuse "magic" that py.test does. Grig -- http://mail.python.org/mailman/listinfo/python-list

Re: unittest vs py.test?

On Mon, 04 Apr 2005 22:50:35 +, John J. Lee wrote: > What I don't understand about py.test (and trying it out seems > unlikely to answer this) is why it uses the assert statement. > unittest used to do that, too, but then it was pointed out that that > breaks when python -O is used, so unittest

Re: unittest vs py.test?

"Raymond Hettinger" <[EMAIL PROTECTED]> writes: > [Peter Hansen] > > (I'm not dissing py.test, and intend to check it > > out. > > Not to be disrepectful, but objections raised by someone > who hasn't worked with both tools equate to hot air. [...] Why? Peter had a reasonable question which, AF

Re: unittest vs py.test?

Peter Hansen <[EMAIL PROTECTED]> wrote: >It seems possible to me that I might have helped him >solely by pointing out that unittest might not be so >"heavy" as some people claimed. I got the impression >that he might be swayed by some unfounded claims not >even to look further at unittest, which

Re: unittest vs py.test?

Raymond Hettinger wrote: [Peter Hansen] (I'm not dissing py.test, and intend to check it out. Not to be disrepectful, but objections raised by someone who hasn't worked with both tools equate to hot air. Not to be disrespectful either, but criticism by someone who has completely missed my point (an

Re: unittest vs py.test?

Paul Rubin wrote: "Terry Reedy" <[EMAIL PROTECTED]> writes: But assert statements vanish when you turn on the optimizer. If you're going to run your application with the optimizer turned on, I certainly hope you run your regression tests with the optimizer on. I don't see why you think so. Assert

Re: unittest vs py.test?

Scott David Daniels <[EMAIL PROTECTED]> wrote: > Any code depending upon __debug__ being 0 won't be tested. Sometimes > test structures update values as a side-effect of tracking the debugging > state. Not massively likely, but it makes for a scary environment when > your tests cannot be run on a

Re: unittest vs py.test?

"Terry Reedy" <[EMAIL PROTECTED]> writes: > > But assert statements vanish when you turn on the optimizer. If > > you're going to run your application with the optimizer turned on, I > > certainly hope you run your regression tests with the optimizer on. > > I don't see why you think so. Asserti

Re: unittest vs py.test?

"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message news:[EMAIL PROTECTED] > "Raymond Hettinger" <[EMAIL PROTECTED]> writes: >> When writing a large suite, you quick come to appreciate being able >> to use assert statements with regular comparision operators, debugging >> with normal p

Re: unittest vs py.test?

In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > "Raymond Hettinger" <[EMAIL PROTECTED]> writes: > > When writing a large suite, you quick come to appreciate being able > > to use assert statements with regular comparision operators, debugging > > with normal print s

Re: unittest vs py.test?

"Raymond Hettinger" <[EMAIL PROTECTED]> writes: > When writing a large suite, you quick come to appreciate being able > to use assert statements with regular comparision operators, debugging > with normal print statements, and not writing self.assertEqual over and > over again. The generative test

Re: unittest vs py.test?

[Peter Hansen] > (I'm not dissing py.test, and intend to check it > out. Not to be disrepectful, but objections raised by someone who hasn't worked with both tools equate to hot air. > I'm just objecting to claims that unittest > somehow is "heavy", when those claiming that it > is seem to think

Re: unittest vs py.test?

Raymond Hettinger wrote: [Peter Hansen] This is pretty, but I *want* my tests to be contained in separate functions or methods. In py.test, those would read: def test1(): assert a == b def test2(): raises(Error, func, args) Enclosing classes are optional. So basically py.test skips the imp

Re: unittest vs py.test?

Roy Smith wrote: Actually, I believe it does. I'm just starting to play with this, but it looks like you can do: py.test test_sample.py and it'll run a single test file. Well, my driver script can do that too. I just meant I could do "test_sample.py" and have it run the test any time, if I wa

Re: unittest vs py.test?

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bengt Richter) > Is there a package that is accessible without svn? That seems to be its weak point right now. Fortunately, you can get pre-built svn clients for many platforms (http://subversion.tigris.org/project_packages.html#binary-packages

Re: unittest vs py.test?

On Sat, 02 Apr 2005 09:24:30 GMT, "Raymond Hettinger" <[EMAIL PROTECTED]> wrote: >[Peter Hansen] >> If py.test provides a driver utility that does >> effectively this, well, that's nice for users. If >> it doesn't run them as separate processes, it wouldn't >> suit me anyway. >> >> Still, it soun

Re: unittest vs py.test?

[Peter Hansen] > This is pretty, but I *want* my tests to be contained > in separate functions or methods. In py.test, those would read: def test1(): assert a == b def test2(): raises(Error, func, args) Enclosing classes are optional. Raymond -- http://mail.python.org/mailman/listi

Re: unittest vs py.test?

[Peter Hansen] > If py.test provides a driver utility that does > effectively this, well, that's nice for users. If > it doesn't run them as separate processes, it wouldn't > suit me anyway. > > Still, it sounds like it does have a strong following > of smart people: enough to make me want to take

Re: unittest vs py.test?

In article <[EMAIL PROTECTED]>, Peter Hansen <[EMAIL PROTECTED]> wrote: > As for Roy's comments: I use a small internally > developed driver script which uses os.walk to find > all the files matching tests/*_unit.py or tests/story*.py > in all subfolders of the project, and which runs them > in s

Re: unittest vs py.test?

Raymond Hettinger wrote: BTW, the above code simplifies to: from py.test import raises assert a == b raises(Error, func, args) This is pretty, but I *want* my tests to be contained in separate functions or methods. The trivial amount of extra overhead that unittest requires fits with the way I wan

Re: unittest vs py.test?

[Peter Hansen] > unittest can really be rather light. Most of our > test cases are variations on the following, with > primarily application-specific code added rather than > boilerplate or other unittest-related stuff: > > import unittest > > class TestCase(unittest.TestCase): > def test01(s

Re: unittest vs py.test?

Peter Hansen <[EMAIL PROTECTED]> wrote: > unittest can really be rather light. Most of our > test cases are variations on the following, with > primarily application-specific code added rather than > boilerplate or other unittest-related stuff: > > import unittest > > class TestCase(unittest.Tes

Re: unittest vs py.test?

Colin J. Williams wrote: unittest seems rather heavy. I don't like mixing tests with documentation, it gives the whole thing a cluttered look. unittest can really be rather light. Most of our test cases are variations on the following, with primarily application-specific code added rather than b

Re: unittest vs py.test?

Grig Gheorghiu wrote: In my mind, practicing TDD is what matters most. Which framework you choose is a function of your actual needs. The fact that there are 3 of them doesn't really bother me. I think it's better to have a choice from a small number of frameworks rather than have no choice or have

Re: unittest vs py.test?

>From what I know, the PyPy guys already have a unittest-to-py.test translator working, but they didn't check in the code yet. You can send an email to py-dev at codespeak.net and let them know you're interested in this functionality. Grig -- http://mail.python.org/mailman/listinfo/python-list

Re: unittest vs py.test?

On Fri, 01 Apr 2005 16:42:30 +, Raymond Hettinger wrote: > FWIW, the evolution of py.test is to also work seemlessly with existing tests > from the unittest module. Is this true now, or is this planned? I read(/skimmed) the docs for py.test when you linked to the project, but I don't recall

Re: unittest vs py.test?

[Roy Smith <[EMAIL PROTECTED]>] > One thing that worries me a little is that all three seem to have > advantages and disadvantages, yet none is so obviously better than the > others that it stands out as the only reasonable way to do it. This means > some groups will adopt one, some will adopt an

Re: unittest vs py.test?

In my mind, practicing TDD is what matters most. Which framework you choose is a function of your actual needs. The fact that there are 3 of them doesn't really bother me. I think it's better to have a choice from a small number of frameworks rather than have no choice or have a single choice that

Re: unittest vs py.test?

Nigel Rowe <[EMAIL PROTECTED]> wrote: > Have you seen Grig Gheorghiu's 3 part comparison of unittest, and py.test? > > http://agiletesting.blogspot.com/2005/01/python-unit-testing-part-1-unittest.html > http://agiletesting.blogspot.com/2005/01/python-unit-testing-part-2-doctest.html > http://agil

Re: unittest vs py.test?

Nigel Rowe>Have you seen Grig Gheorghiu's 3 part comparison of unittest, and py.test?< Very interesting articles, thank you. Testing seems something still in quick development. For small functions the doctests are useful, but py.test has some advantages. Probably something even better that py.tes

Re: unittest vs py.test?

Roy Smith wrote: > I've used the standard unittest (pyunit) module on a few projects in the > past and have always thought it basicly worked fine but was just a little > too complicated for what it did. > > I'm starting a new project now and I'm thinking of trying py.test > (http://codespeak.net/

Re: unittest vs py.test?

[Roy Smith] > I've used the standard unittest (pyunit) module on a few projects in the > past and have always thought it basicly worked fine but was just a little > too complicated for what it did. > > I'm starting a new project now and I'm thinking of trying py.test > (http://codespeak.net/py/curr

unittest vs py.test?

I've used the standard unittest (pyunit) module on a few projects in the past and have always thought it basicly worked fine but was just a little too complicated for what it did. I'm starting a new project now and I'm thinking of trying py.test (http://codespeak.net/py/current/doc/test.html).