Re: Unit testing asynchronous processes

On 12/10/2013 9:24 PM, Tim Chase wrote: I've got some code that kicks off a background request to a remote server over an SSL connection using client-side certificates. Since the request is made from a separate thread, I'm having trouble testing that everything is working without without spinnin

Re: unit testing class hierarchies

On 10/3/2012 5:33 AM, Oscar Benjamin wrote: On 3 October 2012 02:20, Steven D'Aprano wrote: But surely, regardless of where that functionality is defined, you still need to test that both D1 and D2 exhibit the correct behaviour? Otherwise D2 (say) may break that functionality and your tests wo

Re: unit testing class hierarchies

On 3 October 2012 02:20, Steven D'Aprano wrote: > > But surely, regardless of where that functionality is defined, you still > need to test that both D1 and D2 exhibit the correct behaviour? Otherwise > D2 (say) may break that functionality and your tests won't notice. > > Given a class hierarchy

Re: unit testing class hierarchies

On Wed, 03 Oct 2012 08:30:19 +1000, Ben Finney wrote: > Ulrich Eckhardt writes: > >> I want test_base() to be run as part of both TestD1 and TestD2, because >> it tests basic functions provided by both classes D1 and D2. > > It sounds, from your description so far, that you have identified a >

Re: unit testing class hierarchies

In article , Peter Otten <__pete...@web.de> wrote: > >> Another is to remove it from the global namespace with > >> > >> del TestBase When I had this problem, that's the solution I used. -- http://mail.python.org/mailman/listinfo/python-list

Re: unit testing class hierarchies

Ulrich Eckhardt writes: > I want test_base() to be run as part of both TestD1 and TestD2, > because it tests basic functions provided by both classes D1 and D2. It sounds, from your description so far, that you have identified a design flaw in D1 and D2. The common functionality should be moved

Re: unit testing class hierarchies

On 02/10/2012 19:06, Demian Brecht wrote: Am I missing something? Is there something that wasn't answered by my reply about using mixins? from unittest import TestCase class SharedTestMixin(object): def test_shared(self): self.assertNotEquals('foo', 'bar') class TestA(TestCase, S

Re: unit testing class hierarchies

Am I missing something? Is there something that wasn't answered by my reply about using mixins? from unittest import TestCase class SharedTestMixin(object): def test_shared(self): self.assertNotEquals('foo', 'bar') class TestA(TestCase, SharedTestMixin): def test_a(self):

Re: unit testing class hierarchies

Am I missing something? Is there something that wasn't answered by my reply about using mixins? from unittest import TestCase class SharedTestMixin(object): def test_shared(self): self.assertNotEquals('foo', 'bar') class TestA(TestCase, SharedTestMixin): def test_a(self):

Re: unit testing class hierarchies

Fayaz Yusuf Khan wrote: > Peter Otten wrote: > >> Ulrich Eckhardt wrote: >>> The problem here is that TestBase is not a complete test case (just > as >>> class Base is not complete), but the unittest framework will still > try >>> to run it on its own. > How exactly are you invoking the test runn

Re: unit testing class hierarchies

Ulrich Eckhardt wrote: > Am 02.10.2012 16:06, schrieb Thomas Bach: >> On Tue, Oct 02, 2012 at 02:27:11PM +0200, Ulrich Eckhardt wrote: >>> As you see, the code for test_base() is redundant, so the idea is to >>> move it to a baseclass: >>> >>> class TestBase(unittest.TestCase): >>> def test_b

Re: unit testing class hierarchies

Am 02.10.2012 16:06, schrieb Thomas Bach: On Tue, Oct 02, 2012 at 02:27:11PM +0200, Ulrich Eckhardt wrote: As you see, the code for test_base() is redundant, so the idea is to move it to a baseclass: class TestBase(unittest.TestCase): def test_base(self): ... class TestD1(TestBas

Re: unit testing class hierarchies

Am 02.10.2012 16:06, schrieb Thomas Bach: On Tue, Oct 02, 2012 at 02:27:11PM +0200, Ulrich Eckhardt wrote: As you see, the code for test_base() is redundant, so the idea is to move it to a baseclass: class TestBase(unittest.TestCase): def test_base(self): ... class TestD1(TestBas

Re: unit testing class hierarchies

Peter Otten wrote: > Ulrich Eckhardt wrote: >> The problem here is that TestBase is not a complete test case (just as >> class Base is not complete), but the unittest framework will still try >> to run it on its own. How exactly are you invoking the test runner? unittest? nose? You can tell the

Re: unit testing class hierarchies

Ulrich Eckhardt wrote: > As you see, the code for test_base() is redundant, so the idea is to > move it to a baseclass: > > class TestBase(unittest.TestCase): > def test_base(self): > ... > > class TestD1(TestBase): > def test_r(self): > ... > def test_s(self): >

Re: unit testing class hierarchies

On Tue, Oct 02, 2012 at 02:27:11PM +0200, Ulrich Eckhardt wrote: > As you see, the code for test_base() is redundant, so the idea is to > move it to a baseclass: > > class TestBase(unittest.TestCase): > def test_base(self): > ... > > class TestD1(TestBase): > def test_r(self): >

Re: unit testing class hierarchies

[1] in C++ I would call that a "mixin" Mixins are perfectly valid Python constructs as well and are perfectly valid (imho) for this use case. On a side note, I usually append a "Mixin" suffix to my mixin classes in order to make it obvious to the reader. -- Demian Brecht @demianbrecht ht

Re: Unit testing beginner question

In article , Ian Kelly wrote: > This would work: > > self.assertRaises(TypeError, lambda: self.testListNone[:1]) If you're using the version of unittest from python 2.7, there's an even nicer way to write this: with self.assertRaises(TypeError): self.testListNone[:1] -- http://mail.pyth

Re: Unit testing beginner question

On Mon, May 23, 2011 at 4:30 PM, Andrius wrote: > and I am expecting test to pass, but I am getting exception: > Traceback (most recent call last): >    self.assertRaises(TypeError, self.testListNone[:1]) > TypeError: 'NoneType' object is unsubscriptable > > I thought that assertRaises will pass s

Re: Unit testing beginner question

That was quick! Thanks Ian On 23 May 2011 23:46, Ian Kelly wrote: > On Mon, May 23, 2011 at 4:30 PM, Andrius wrote: > > and I am expecting test to pass, but I am getting exception: > > Traceback (most recent call last): > >self.assertRaises(TypeError, self.testListNone[:1]) > > TypeError:

Re: Unit testing multiprocessing code on Windows

Il Thu, 17 Feb 2011 18:31:59 -0500, Matt Chaput ha scritto: > > The problem is that with both "python setup.py tests" and "nosetests", > Maybe multiprocessing is starting new Windows processes by copying the > command line of the current process? But if the command line is > "nosetests", it's

Re: Unit testing multiprocessing code on Windows

On 17/02/2011 8:22 PM, phi...@semanchuk.com wrote: Hi Matt, I assume you're aware of this documentation, especially the item entitled "Safe importing of main module"? http://docs.python.org/release/2.6.6/library/multiprocessing.html#windows Yes, but the thing is my code isn't __main__, my uni

Re: Unit testing multiprocessing code on Windows

On 18/02/2011 2:54 AM, Terry Reedy wrote: On 2/17/2011 6:31 PM, Matt Chaput wrote: Does anyone know the "right" way to write a unit test for code that uses multiprocessing on Windows? I would start with Lib/test/test_multiprocessing. Good idea, but on the one hand it doesn't seem to be doing

Re: Unit testing multiprocessing code on Windows

On 2/17/2011 6:31 PM, Matt Chaput wrote: Does anyone know the "right" way to write a unit test for code that uses multiprocessing on Windows? I would start with Lib/test/test_multiprocessing. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list

Re: Unit testing multiprocessing code on Windows

Quoting Matt Chaput : Does anyone know the "right" way to write a unit test for code that uses multiprocessing on Windows? The problem is that with both "python setup.py tests" and "nosetests", when they get to testing any code that starts Processes they spawn multiple copies of the testi

Re: Unit testing errors (testing the platform module)

On 4/14/2010 11:19 AM, J. Cliff Dyer wrote: On Wed, 2010-04-14 at 15:51 +0100, john maclean wrote: self.assertEqual(platform.__builtins__.__class__, dict, "platform.__class__ supposed to be dict") self.assertEqual(platform.__name__, 'platform' ) The preferred spelling for: platform.__bui

Re: unit testing, setUp and scoping

On 14 April 2010 16:22, Francisco Souza wrote: >> On Wed, Apr 14, 2010 at 11:47 AM, john maclean wrote: >> Can one use the setUp block to store variables so that they can be >> used elsewhere in unit tests? I'm thinking that it's better to have >> variables created in another script and have it i

Re: unit testing, setUp and scoping

> > On Wed, Apr 14, 2010 at 11:47 AM, john maclean wrote: > Can one use the setUp block to store variables so that they can be > used elsewhere in unit tests? I'm thinking that it's better to have > variables created in another script and have it imported from within > the unit test > Hi John, ea

Re: Unit testing errors (testing the platform module)

On Wed, 2010-04-14 at 15:51 +0100, john maclean wrote: > self.assertEqual(platform.__builtins__.__class__, dict, > "platform.__class__ supposed to be dict") > self.assertEqual(platform.__name__, 'platform' ) The preferred spelling for: platform.__builtins__.__class__ would be type(pla

Re: unit testing, setUp and scoping

john maclean a écrit : Can one use the setUp block to store variables so that they can be used elsewhere in unit tests? I'm thinking that it's better to have variables created in another script and have it imported from within the unit test ??? #!/usr/bin/env python '''create knowledge base

Re: Unit testing errors (testing the platform module)

On 14 April 2010 09:09, Gabriel Genellina wrote: > En Tue, 13 Apr 2010 11:01:19 -0300, John Maclean > escribió: > >> Is there an error in my syntax? Why is my test failing? Line 16. >> >> == >> FAIL: platform.__builtins__.blah >>

Re: Unit testing errors (testing the platform module)

En Tue, 13 Apr 2010 11:01:19 -0300, John Maclean escribió: Is there an error in my syntax? Why is my test failing? Line 16. == FAIL: platform.__builtins__.blah

Re: Unit testing errors (testing the platform module)

The problem is that the class of platform.__builtins__ is a dict, not a string containing the text "". Try replacing line 16 with this: self.assertEqual(type(platform.__builtins__), dict) Cheers, Cliff On Tue, 2010-04-13 at 15:01 +0100, John Maclean wrote: > I normally use languages uni

Re: Unit testing errors (testing the platform module)

John Maclean wrote: I normally use languages unit testing framework to get a better understanding of how a language works. Right now I want to grok the platform module; 1 #!/usr/bin/env python 2 '''a pythonic factor''' 3 import unittest 4 import platform 5 6 class TestPyfactorTestCa

Re: Unit testing errors (testing the platform module)

On 04/13/10 15:01, John Maclean wrote: I normally use languages unit testing framework to get a better understanding of how a language works. Right now I want to grok the platform module; 1 #!/usr/bin/env python 2 '''a pythonic factor''' 3 import unittest 4 import platform 5 6

Re: Unit testing errors (testing the platform module)

On Tue, Apr 13, 2010 at 10:01 AM, John Maclean wrote: > I normally use languages unit testing framework to get a better > understanding of how a language works. Right now I want to grok the > platform module; > > > 1 #!/usr/bin/env python > 2 '''a pythonic factor''' > 3 import unittest > 4 i

Re: unit testing a routine that sends mail

commander_coder a écrit : Hello, I have a routine that sends an email (this is how a Django view notifies me that an event has happened). I want to unit test that routine. http://docs.djangoproject.com/en/dev/topics/email/#e-mail-backends Or if you're stuck with 1.x < 1.2a, you could just

Re: unit testing a routine that sends mail

commander_coder wrote: > I have a routine that sends an email (this is how a Django view > notifies me that an event has happened).  I want to unit test that > routine. Are you opening SMTP and POP3 sockets?? If you are not developing that layer itself, just use Django's built- in mock system. H

Re: unit testing a routine that sends mail

Bruno, I talked to someone who explained to me how what you said gives a way around my difficulty. Please ignore the other reply. I'll do what you said. Thank you; I appreciate your help. Jim -- http://mail.python.org/mailman/listinfo/python-list

Re: unit testing a routine that sends mail

On Feb 18, 10:27 am, Bruno Desthuilliers wrote: > you could just mock the send_mail > function to test that your app does send the appropriate mail - which is > what you really want to know. That's essentially what I think I am doing. I need to send a relatively complex email, multipart, with b

Re: unit testing a routine that sends mail

On Feb 18, 9:55 am, Roy Smith wrote: > Just a wild guess here, but maybe there's some DNS server which > round-robins three address records for some hostname you're using, one of > which is bogus. > > I've seen that before, and this smells like the right symptoms. Everything happens on my laptop,

Re: unit testing a routine that sends mail

In article , commander_coder wrote: > The real puzzler for me is that the test reliably fails every third > time. For instance, if I try it six times then it succeeds the first, > second, fourth, and fifth times. I have to say that I cannot > understand this at all but it certainly makes the

Re: Unit testing frameworks

Hi, I'm work on a testing framework for Python. Until now I have implemented the main features of PyUnit and JUnit 4.x. I like the annotation syntax of JUnit 4.x and it's theory concept is great therefore you can imagine how my framework will be. I plan a lot of additionally features which are n

Re: Unit testing frameworks

> sorry for not reporting a bug - i assumed you'd know (and the workarounds > described above meant i wasn't stalled). > > i also have eclipse 3.4.2 with pydev 1.4.4.2636 on a separate machine (ie > new versions), and i can try there if you want (it will take a while to > get the source there, but

Re: Unit testing frameworks

In unittest, has anyone used the *NIX command "find" to automatically build a test suite file of all tests under a specified directory? I generally name my tests as _Test_ORIGINAL_MODULE_NAME.py where ORIGINAL_MODULE_NAME is the obvious value. This way, I can include/ exclude them from deployments

Re: Unit testing frameworks

copy+paste error; the correct Python2.6 details are: Python 2.6 (r26:66714, Feb 3 2009, 20:49:49) andrew cooke wrote: > this is with a homebuilt 3.0 - Python 3.0 (r30:67503, Jan 16 2009, > 06:50:19) and opensuse's default 2.6 - Python 3.0 (r30:67503, Jan 16 2009, > 06:50:19) - on Eclipse 3.3.2

Re: Unit testing frameworks

Fabio Zadrozny wrote: >> not exactly a framework, but useful while working on small projects - >> you >> can run tests from inside eclipse (using the pydev plugin for python). >> it's easy to run all tests or some small subset (although it is a bit >> buggy for 3.0). > > What exactly is not working

Re: Unit testing frameworks

Hi Andew, > not exactly a framework, but useful while working on small projects - you > can run tests from inside eclipse (using the pydev plugin for python). > it's easy to run all tests or some small subset (although it is a bit > buggy for 3.0). What exactly is not working with 3.0? (couldn't

Re: Unit testing frameworks

En Tue, 24 Mar 2009 09:06:47 -0300, escribió: I am looking for a unit testing framework for Python. I am aware of nose, but was wondering if there are any others that will automatically find and run all tests under a directory hierarchy. All known testing tools (and some unknown too): http:/

Re: Unit testing frameworks

On Mar 24, 8:06 am, grkunt...@gmail.com wrote: > I am looking for a unit testing framework for Python. I am aware of > nose, but was wondering if there are any others that will > automatically find and run all tests under a directory hierarchy. > > Thanks, Ralph *Nose *Trial *py.test -- http://mai

Re: Unit testing frameworks

On Tue, Mar 24, 2009 at 8:06 AM, wrote: > I am looking for a unit testing framework for Python. I am aware of > nose, but was wondering if there are any others that will > automatically find and run all tests under a directory hierarchy. Have you already looked at the unittest module? Below is t

Re: Unit testing frameworks

grkunt...@gmail.com wrote: > I am looking for a unit testing framework for Python. I am aware of > nose, but was wondering if there are any others that will > automatically find and run all tests under a directory hierarchy. not exactly a framework, but useful while working on small projects - you

Re: Unit testing frameworks

On Tue, 24 Mar 2009 05:06:47 -0700 (PDT), grkunt...@gmail.com wrote: I am looking for a unit testing framework for Python. I am aware of nose, but was wondering if there are any others that will automatically find and run all tests under a directory hierarchy. One such tool is trial, http://twi

Re: Unit Testing: a couple of questions

Thank you all for the very instructive replies! Much appreciated! By the sound of it I just have to relax a little and acquire a little bit more experience on the matter as I go along. =) Thank you again! Manu -- http://mail.python.org/mailman/listinfo/python-list

Re: Unit Testing: a couple of questions

On Tue, Oct 28, 2008 at 3:56 PM, Emanuele D'Arrigo <[EMAIL PROTECTED]> wrote: > Hi everybody, > > I'm just having a go with Unit Testing for the first time and my > feeling about it in short is: Neat! > > I'm a bit worried about the time it's taking me to develop the tests > but after only a day or

Re: Unit Testing: a couple of questions

Emanuele D'Arrigo wrote: > I'm a bit worried about the time it's taking me to develop the tests > but after only a day or so I'm already much faster than when I started > with it and the code is already much improved in terms of robustness. > A couple of "philosophical" questions have emerged in th

Re: Unit Testing: a couple of questions

For the first bit, a colleague has recently asked the philosophical question, "How do you test what happens when the power goes down?" :) In other words, only test the bits that your code does. If you want to provide type checking, then yes, you have to test that. It's fair to assume that everyth

Re: Unit Testing: a couple of questions

I'm wondering if don't want your class to look something like this: class myClass(): def __init__(self, data): self.__data = data def getData(self): return self.__data def setData(self, data): self.__data = data For the rest I'll let the experts argue, I don

Re: Unit Testing Techniques

I'm by no means a testing expert, but I'll take a crack at it. Casey McGinty wrote: I'm familiar with the unittest module in Python, however I'm hoping someone can point me to some examples of more advanced usages of the framework. For example: 1. Using the framework to test a package with ne

RE: Unit testing Web applications

> On Behalf Of Monica Leko > Does Python has some testing frameworks for testing Web > applications (like Cactus and HttpUnit for Java), generating > requests and checking if the response is correct? I have got a lot of traction using mechanize [1] with nose [2]. Of course that still leaves out

Re: Unit testing Web applications

Monica Leko wrote: > Hi! > > Does Python has some testing frameworks for testing Web applications > (like Cactus and HttpUnit for Java), generating requests and checking > if the response is correct? mechanize and webunit come to my mind. Yet the most powerful will be selenium together with sel

Re: unit testing

[EMAIL PROTECTED] 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 b

Re: unit testing

Paul Rubin writes: > Ben Finney <[EMAIL PROTECTED]> writes: > > Or even better: > > > > def test_raises_good_exception(): > > try: > > thingy() > > Well if we're grading on style, maybe you really want to name the > function 'test_thingy' instea

Re: unit testing

Ben Finney <[EMAIL PROTECTED]> writes: > Or even better: > > def test_raises_good_exception(): > try: > thingy() Well if we're grading on style, maybe you really want to name the function 'test_thingy' instead of 'test_raises_good_exception'. -- http://mail.python.org/mai

Re: unit testing

Ben Finney <[EMAIL PROTECTED]> writes: > Paul Rubin writes: > > > Giampaolo Rodolà <[EMAIL PROTECTED]> writes: > > > What's the equivalent of unittest's "assertRaises"? > > > > def test_raises(): > > try: > >thingy() > >assert 42 == 43 > > Clearer

Re: unit testing

Paul Rubin writes: > Giampaolo Rodolà <[EMAIL PROTECTED]> writes: > > def test_answer(): > > assert 42 == 43 > > > > What's the equivalent of unittest's "assertRaises"? > > def test_raises(): > try: >thingy() >assert 42 == 43 Clearer would be:

Re: unit testing

> What's the equivalent of unittest's "assertRaises"? > 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/ B

Re: unit testing

Giampaolo Rodolà <[EMAIL PROTECTED]> writes: > def test_answer(): > assert 42 == 43 > > What's the equivalent of unittest's "assertRaises"? def test_raises(): try: thingy() assert 42 == 43 except GoodException: pass -- http://mail.python.org/mailman/listinfo/pyth

Re: unit testing

[EMAIL PROTECTED] 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

Re: unit testing

On 3 Ott, 14:37, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Paul Rubin a écrit : > > > brad <[EMAIL PROTECTED]> writes: > > >>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, unit

Re: unit testing

7stud <[EMAIL PROTECTED]> writes: > What are some strategies for unit testing a function that obtains user > input? For example: http://en.wikipedia.org/wiki/Expect -- http://mail.python.org/mailman/listinfo/python-list

Re: unit testing

What are some strategies for unit testing a function that obtains user input? Thanks. -- http://mail.python.org/mailman/listinfo/python-list

Re: unit testing

On Oct 5, 4:12 pm, [EMAIL PROTECTED] wrote: > On Oct 5, 5:38 am, Craig Howard <[EMAIL PROTECTED]> wrote: > > > 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 sma

Re: unit testing

[EMAIL PROTECTED] wrote: > 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

Re: unit testing

[EMAIL PROTECTED] wrote: > On Oct 5, 5:38 am, Craig Howard <[EMAIL PROTECTED]> wrote: >> 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

Re: unit testing

On Oct 5, 5:38 am, Craig Howard <[EMAIL PROTECTED]> wrote: > 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 sys

Re: unit testing

On Oct 4, 9:39 pm, Paul Rubin wrote: > Yeah, unittest is sort of a Java-ism. However legend tells the story of Kent Beck and Erich Gamma sitting together in a plane to ( or from ) New York and porting a unittest framework from SmallTalk to Java. This extreme programming

Re: unit testing

On Oct 3, 2:37 pm, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Paul Rubin a écrit : > > > brad <[EMAIL PROTECTED]> writes: > > >>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, un

Re: unit testing

On 4 Okt., 22:49, Jeffrey Froman <[EMAIL PROTECTED]> wrote: > Chris Mellon wrote: > > Doctest is commonly given as the alternative to people who feel this > > way. Personally, I find that anything worth testing is worth having a > > test directory and independent unit tests for. > > I like keeping

Re: unit testing

On Oct 4, 2007, at 3:02 PM, brad wrote: > Does anyone else feel that unittesting is too much work? Not in > general, > just the official unittest module for small to medium sized projects? > > It seems easier to write some quick methods that are used when needed > rather than building a program

RE: unit testing

> On Behalf Of Bruno Desthuilliers > Or py.test or nose, which are both more complete than doctest > and more pythonics than the unittest module. I second the recommendation of nose. It makes it fantastically easy to write and run unit tests. Also, in my experience unit tests help reduce bugs in

Re: unit testing

Chris Mellon wrote: > Doctest is commonly given as the alternative to people who feel this > way. Personally, I find that anything worth testing is worth having a > test directory and independent unit tests for. I like keeping my tests separate as well, and doctest does allow this, using doctest.

Re: unit testing

>>> Does anyone else feel that unittesting is too much work? Not in general, >>> just the official unittest module for small to medium sized projects? > [snip] >> I actually do a lot of unit testing. I find it both annoying and >> highly necessary and useful. > > +1 QOTW. > > I feel exactly the

Re: unit testing

Paul Rubin a écrit : > brad <[EMAIL PROTECTED]> writes: > >>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 ins

Re: unit testing

[EMAIL PROTECTED] wrote: > On Oct 4, 1:02 pm, brad <[EMAIL PROTECTED]> wrote: >> Does anyone else feel that unittesting is too much work? Not in general, >> just the official unittest module for small to medium sized projects? [snip] > I actually do a lot of unit testing. I find it both annoying a

Re: unit testing

brad <[EMAIL PROTECTED]> writes: > 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. -- http://mail.python.org/ma

Re: unit testing

On Oct 4, 1:02 pm, brad <[EMAIL PROTECTED]> wrote: > Does anyone else feel that unittesting is too much work? Not in general, > just the official unittest module for small to medium sized projects? > > It seems easier to write some quick methods that are used when needed > rather than building a pr

Re: unit testing

On 10/4/07, brad <[EMAIL PROTECTED]> wrote: > Does anyone else feel that unittesting is too much work? Not in general, > just the official unittest module for small to medium sized projects? > > It seems easier to write some quick methods that are used when needed > rather than building a program w

Re: unit testing

Steve Howell skrev: > And, really, if > you're not doing automated tests on your application > now, you don't know what you're missing. Quote of the day, IMO. Nis -- http://mail.python.org/mailman/listinfo/python-list

Re: unit testing

Let me preface every reply here by YMMV. I strongly, strongly encourage people to tap into the unit testing community for all tools that are available to them. Also, let me say that despite any place where Steven and I disagree about the mechanics of unit testing, we're in firm agreement that UNI

Re: unit testing

Steve Howell wrote: > --- Steven Bethard <[EMAIL PROTECTED]> wrote: >> Have you tried py.test? >> >> http://codespeak.net/py/dist/test.html >> >> I've heard good things about it, but haven't gotten >> around to trying it >> yet. Here's a two-line test suite from the page >> above: >> >>

Re: unit testing failure makes no sense

[EMAIL PROTECTED] wrote: > I have some unit testing code in one of my modules that appears to > run without an error, but the unit test fails anyhow. Have a look at > the output below -- the TestResult seems to have no errors and no > failures, yet I get a system exit. unittest.main() ALWAYS rais

Re: unit testing failure makes no sense

[EMAIL PROTECTED] wrote: > I have some unit testing code in one of my modules that appears to > run without an error, but the unit test fails anyhow. Have a look at > the output below -- the TestResult seems to have no errors and no > failures, yet I get a system exit. sys.exit(0) is just a norma

Re: Unit testing - one test class/method, or test class/class

"John Roth" <[EMAIL PROTECTED]> writes: > I tend to write one test class per class, but that's > just the way I got started. My feeling is that the > methods in a test class should tell a story if you > read the names in the order they were written, > so I'd split the tests for a class into severa

Re: Unit testing - one test class/method, or test class/class

aurora <[EMAIL PROTECTED]> writes: > What I really want to bring up is your might want to look at refactoring > your module in the first place. 348 test cases for one module sounds like a > large number. That reflects you have a fairly complex module to be tested > to start with. Often the bigges

Re: Unit testing - one test class/method, or test class/class

I tend to write one test class per class, but that's just the way I got started. My feeling is that the methods in a test class should tell a story if you read the names in the order they were written, so I'd split the tests for a class into several classes if they had different stories to tell. Jo

Re: Unit testing - one test class/method, or test class/class

I do something more or less like your option b. I don't think there is any orthodox structure to follow. You should use a style that fit your taste. What I really want to bring up is your might want to look at refactoring your module in the first place. 348 test cases for one module sounds lik

Re: Unit Testing in Python

No-nonsense PyUnit skeleton: http://www.python.org/moin/PyUnit Copy & Paste. Though there's a new module, [http://codespeak.net/py/current/doc/test.html py.test,] that's easier in many ways. -- http://mail.python.org/mailman/listinfo/python-list

Re: Unit Testing in Python

A great place to start for TDD-related stuff is testdriven.com. On the topic of Python-specific unit testing, there's also a recent thread on the newly-created extreme-python google group: http://groups-beta.google.com/group/extreme-python/browse_thread/thread/f39844c4cf6c844f?tvc=2 Grig htt

Re: Unit Testing in Python

I've had great experience doing Test Driven Development. Ideally you would do it from the start, but it is great for refactoring as well. In any language. One of the pitfalls to look out for is to not get too hung up on it. In the end it's just a tool you use at your discretion. When I first star

  1   2   >