Re: unittest basics

import unittest class MyTestCase(unittest.TestCase): def test_my_import(self): import blah cheers, Chris John Maclean wrote: is there a way to test that a certian library or module is or can be loaded successfully? self.assert('import blah') -- Simplistix - Content

Re: unittest basics

There's no reason for such a thing. You can just make "import module" in your test and if something goes wrong that will be treated as any other test failure. --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil 2010/5/11 John Maclean : > is there a way to test that a

unittest basics

is there a way to test that a certian library or module is or can be loaded successfully? self.assert('import blah') -- John Maclean MSc. (DIC) BSc. (Hons) Linux Systems and Applications 07739 171 531 -- http://mail.python.org/mailman/listinfo/python-list

Re: unittest not being run

On Mon, May 10, 2010 at 5:17 PM, cjw wrote: > PyScripter and PythonWin permit the user to choose the equivalence of tabs > and spaces.  I like two spaces = on tab, it's a matter of taste.  I feel > that eight spaces is too much. While it is a matter of taste, PEP 8 recommends 4 spaces per indent

Re: unittest not being run

On 10-May-10 10:21 AM, John Maclean wrote: On 10/05/2010 14:38, J. Cliff Dyer wrote: My guess is you mixed tabs and spaces. One tab is always treated by the python interpreter as being equal to eight spaces, which is two indentation levels in your code. Though if it were exactly as you show it,

Re: unittest not being run

On 10/05/2010 14:38, J. Cliff Dyer wrote: My guess is you mixed tabs and spaces. One tab is always treated by the python interpreter as being equal to eight spaces, which is two indentation levels in your code. Though if it were exactly as you show it, you'd be getting a syntax error, because e

Re: unittest not being run

!/usr/bin/env python > import unittest # {{{ > class T1TestCase(unittest.TestCase): > > def setUp(self): > pass # can we use global variables here? > > def tearDown(self): > pass # garbage collection > > def test_T

Re: unittest not being run

On Mon, May 10, 2010 at 8:38 AM, John Maclean wrote: > hi, > > can some one explain why the __first__ test is not being run? It looks like you defined test_T1 inside of the tearDown method. -- http://mail.python.org/mailman/listinfo/python-list

unittest not being run

hi, can some one explain why the __first__ test is not being run? #!/usr/bin/env python import unittest # {{{ class T1TestCase(unittest.TestCase): def setUp(self): pass # can we use global variables here? def tearDown(self): pass # garbage collection def

2to3 as a unittest

I have used 2to3 from the command line. is there a way to run it as a unittest. Actually I guess my question is; is there a built in utility for running py3 compatibility on source code as a unittest? *Vincent Davis 720-301-3003 * vinc...@vincentdavis.net my blog <http://vincentdavis.

Re: Is HTML report of tests run using PyUnit (unittest) possible?

On Jan 19, 3:16 am, fossist wrote: > I am using PyUnit (unittest module) for loading test cases from our > modules and executing them. Is it possible to export the test results > as HTML report? Currently the results appear as text on standard > output while the tests execute.

Is HTML report of tests run using PyUnit (unittest) possible?

I am using PyUnit (unittest module) for loading test cases from our modules and executing them. Is it possible to export the test results as HTML report? Currently the results appear as text on standard output while the tests execute. But is there something out of the box available in PyUnit to

Re: unittest help needed!

Oltmans wrote: def test_first(self): print 'first test' process(123) All test cases use the pattern "Assemble Activate Assert". You are assembling a 123, and activating process(), but where is your assert? If it is inside process() (if process is a test-side method), then

Re: unittest help needed!

nt to know what's the gurus way of doing it? I've a unittest.TestCase derived class that have around 50 test methods. Design is almost similar to following --- import unittest class result(unittest.TestResult): pass class tee(unittest.TestCase): def test_first(self): pri

Re: unittest help needed!

On 06:33 pm, rolf.oltm...@gmail.com wrote: Hi Python gurus, I'm quite new to Python and have a problem. Following code resides in a file named test.py --- import unittest class result(unittest.TestResult): pass class tee(unittest.TestCase): def test_first(self): print &

unittest help needed!

Hi Python gurus, I'm quite new to Python and have a problem. Following code resides in a file named test.py --- import unittest class result(unittest.TestResult): pass class tee(unittest.TestCase): def test_first(self): print 'first test' print '--

Re: unittest inconsistent

Phlip wrote: The reason the 'Tester' object has no attribute 'arg1' is because "self" still refers to the object made for testA. I hope someone else can spot the low-level reason... ...but why aren't you using http://pypi.python.org/pypi/mock/ ? Look up its patch_object facility... Indeed, I

unittest inconsistent

Can anyone tell me why this test fails? http://pastebin.com/f20039b17 This is a minimal example of a much more complex thing I'm trying to do. I'm trying to hijack a function and inspect the args passed to it by another function. The reason the 'Tester' object has no attribute 'arg1' is because

Re: unittest inconsistent

André wrote: > On Jan 5, 8:14 pm, Matt Haggard wrote: >> Can anyone tell me why this test fails? >> >> http://pastebin.com/f20039b17 >> >> This is a minimal example of a much more complex thing I'm trying to >> do. I'm trying to hijack a function and inspect the args passed to it >> by another f

Re: unittest inconsistent

On Jan 5, 8:14 pm, Matt Haggard wrote: > Can anyone tell me why this test fails? > > http://pastebin.com/f20039b17 > > This is a minimal example of a much more complex thing I'm trying to > do.  I'm trying to hijack a function and inspect the args passed to it > by another function. > > The reason

Re: unittest inconsistent

On Jan 5, 4:14 pm, Matt Haggard wrote: > Can anyone tell me why this test fails? > > http://pastebin.com/f20039b17 > > This is a minimal example of a much more complex thing I'm trying to > do.  I'm trying to hijack a function and inspect the args passed to it > by another function. > > The reason

Re: unittest buffing output on windows?

Roy Smith wrote: I'm running 2.5.1. I've got a test suite that takes about 15 minutes to complete. On my unix boxes, as each test case executes, it prints out a line (I'm using unittest.TextTestRunner(verbosity=2)) of status, but on my windows box (running under cygwin), it buffers everything u

unittest buffing output on windows?

I'm running 2.5.1. I've got a test suite that takes about 15 minutes to complete. On my unix boxes, as each test case executes, it prints out a line (I'm using unittest.TextTestRunner(verbosity=2)) of status, but on my windows box (running under cygwin), it buffers everything until the entire tes

Re: unittest & setup

On Tue, Nov 3, 2009 at 11:02 PM, Jonathan Haddad wrote: > I've got a class, in the constructor it loads a CSV file from disc.  I'd > like only 1 instance of the class to be instantiated.  However, when running > multiple unit tests, multiple instances of the class are created.  What's > the best w

Re: unittest & setup

En Wed, 04 Nov 2009 01:02:24 -0300, Jonathan Haddad escribió: I've got a class, in the constructor it loads a CSV file from disc. I'd like only 1 instance of the class to be instantiated. However, when running multiple unit tests, multiple instances of the class are created. What's the

unittest & setup

Maybe I'm doing something wrong here, definitely not the most experienced unit tester. I've got a class, in the constructor it loads a CSV file from disc. I'd like only 1 instance of the class to be instantiated. However, when running multiple unit tests, multiple instances of the class are crea

Re: unittest wart/bug for assertNotEqual

Gabriel Genellina wrote: En Tue, 20 Oct 2009 19:57:19 -0300, Ethan Furman escribió: Steven D'Aprano wrote: On Tue, 20 Oct 2009 14:45:49 -0700, Zac Burns wrote: My preference would be that failIfEqual checks both != and ==. This is practical, and would benefit almost all use cases. If "!="

Re: unittest wart/bug for assertNotEqual

En Tue, 20 Oct 2009 19:57:19 -0300, Ethan Furman escribió: Steven D'Aprano wrote: On Tue, 20 Oct 2009 14:45:49 -0700, Zac Burns wrote: My preference would be that failIfEqual checks both != and ==. This is practical, and would benefit almost all use cases. If "!=" isn't "not ==" (IEEE NaNs

Re: unittest wart/bug for assertNotEqual

Steven D'Aprano wrote: On Tue, 20 Oct 2009 14:45:49 -0700, Zac Burns wrote: My preference would be that failIfEqual checks both != and ==. This is practical, and would benefit almost all use cases. If "!=" isn't "not ==" (IEEE NaNs I hear is the only known use case) numpy uses == and != as

Re: unittest wart/bug for assertNotEqual

On Tue, 20 Oct 2009 14:45:49 -0700, Zac Burns wrote: > My preference would be that failIfEqual checks both != and ==. This is > practical, and would benefit almost all use cases. If "!=" isn't "not > ==" (IEEE NaNs I hear is the only known use case) numpy uses == and != as element-wise operators:

Re: unittest wart/bug for assertNotEqual

all, the documentation is clear on what it does: > >     |  assertNotEqual = failIfEqual(self, first, second, msg=None) >     |      Fail if the two objects are equal as determined by the '==' >     |      operator. >     | > > > (Taken from help(unittest).) > > > >

Re: unittest wart/bug for assertNotEqual

On Tue, 20 Oct 2009 10:20:54 -0700, Zac Burns wrote: > Using the assertNotEqual method of UnitTest (synonym for failIfEqual) > only checks if first == second, but does not include not (first != > second) > > According to the docs: > http://docs.python.org/reference/datamodel

Re: unittest wart/bug for assertNotEqual

On Oct 20, 6:20 pm, Zac Burns wrote: > Using the assertNotEqual method of UnitTest (synonym for failIfEqual) > only checks if first == second, but does not include not (first != > second) It looks as though this is fixed in Python 2.7 (and also in 3.1): http://svn.python.org/view

unittest wart/bug for assertNotEqual

Using the assertNotEqual method of UnitTest (synonym for failIfEqual) only checks if first == second, but does not include not (first != second) According to the docs: http://docs.python.org/reference/datamodel.html#specialnames There are no implied relationships among the comparison operators

ANN: discover 0.3.0 released, automatic test discovery for unittest

The discover module is a backport of the automatic test discovery from the unittest module in Python-trunk (what will become Python 2.7 and 3.2). The discover module should work on versions of Python 2.4 upwards: * discover module on PyPI: http://pypi.python.org/pypi/discover The discover

Re: unittest

Mag Gam writes: > all, thank you very much!!! > > Now my question is You would do well to ask more about testing in Python on the focussed forum for that topic, the ‘testing-in-python’ mailing list http://lists.idyll.org/listinfo/testing-in-python>. -- \“If it ain't bust don't fix it

Re: unittest

gt; >>> I am writing an application which has many command line arguments. >>> For example: foo.py -args "bar bee" >>> >>> I would like to create a test suit using unittest so when I add >>> features to "foo.py" I don't want to brea

Re: ignored test cases in unittest

On Aug 17, 8:23 pm, David House wrote: > > Note that the unittest module now supports the `skip' and > `expectedFailure' decorators, which seem to describe some of the > solutions here. > > Seehttp:// docs.python.org/3.1/library/unittest.html#skipping-tests-and-e...

Re: ignored test cases in unittest

2009/8/16 Terry : > Thanks for the solutions. I think the decorator idea is what I'm look > for:-) Note that the unittest module now supports the `skip' and `expectedFailure' decorators, which seem to describe some of the solutions here. See http://docs.python.org/3.1/

Re: unittest

foo.py -args "bar bee" >> >> I would like to create a test suit using unittest so when I add >> features to "foo.py" I don't want to break other things. I just heard >> about unittest and would love to use it for this type of thing. >> >> so

Re: ignored test cases in unittest

On Aug 16, 5:25 pm, Duncan Booth wrote: > Ben Finney wrote: > > Terry writes: > > >> It seemed the to me that python unittest module does not support the > >> counting of ignored test cases directly. Is there any ready solution > >> for this? > >

Re: ignored test cases in unittest

Ben Finney wrote: > Terry writes: > >> It seemed the to me that python unittest module does not support the >> counting of ignored test cases directly. Is there any ready solution >> for this? > > One solution I've seen involves: > > *

Re: ignored test cases in unittest

hundred tests you have to do on your > program? > > On Sat, Aug 15, 2009 at 7:04 PM, Terry wrote: > >> Hi, >> >> I have some 100s unittest cases with my python program. And sometimes, >> I did quick-and-dirty work by ignoring some test cases by adding an >>

Re: ignored test cases in unittest

So you are saying you have several hundred tests you have to do on your program? On Sat, Aug 15, 2009 at 7:04 PM, Terry wrote: > Hi, > > I have some 100s unittest cases with my python program. And sometimes, > I did quick-and-dirty work by ignoring some test cases by adding

Re: unittest

like to create a test suit using unittest so when I add > features to "foo.py" I don't want to break other things. I just heard > about unittest and would love to use it for this type of thing. > > so my question is, when I do these tests do I have to code them into > foo.

Re: ignored test cases in unittest

Terry writes: > It seemed the to me that python unittest module does not support the > counting of ignored test cases directly. Is there any ready solution > for this? One solution I've seen involves: * a custom exception class, ‘TestSkipped’ * raising that exception at the top

Re: ignored test cases in unittest

In article , Terry wrote: > Hi, > > I have some 100s unittest cases with my python program. And sometimes, > I did quick-and-dirty work by ignoring some test cases by adding an > 'x' (or something else) to the beginning of the case name. > As time pass by, it'

ignored test cases in unittest

Hi, I have some 100s unittest cases with my python program. And sometimes, I did quick-and-dirty work by ignoring some test cases by adding an 'x' (or something else) to the beginning of the case name. As time pass by, it's very hard for me to find which test cases are ignored. I

Re: unittest

Mag Gam wrote: I am writing an application which has many command line arguments. For example: foo.py -args "bar bee" I would like to create a test suit using unittest so when I add features to "foo.py" I don't want to break other things. I just heard about unittest and

Re: unittest

e unit tests. If you only have a few, you can probably put them inside mymodule.py, but let's say you have lots and want to keep them in a separate file. So create a new module mymoduletests.py, and start it like this: # mymoduletests.py import unittest import mymodule class MyTests(unitt

Re: unittest

ine arguments. >> For example: foo.py -args "bar bee" >> >> I would like to create a test suit using unittest so when I add >> features to "foo.py" I don't want to break other things. I just heard >> about unittest and would love to use it for

Re: unittest

On Aug 15, 4:28 am, Mag Gam wrote: > I am writing an application which has many command line arguments. > For example: foo.py -args "bar bee" > > I would like to create a test suit using unittest so when I add > features to "foo.py" I don't want to

unittest

I am writing an application which has many command line arguments. For example: foo.py -args "bar bee" I would like to create a test suit using unittest so when I add features to "foo.py" I don't want to break other things. I just heard about unittest and would love t

Re: unittest - what is the best way to reuse test data?

On Thu, Jun 4, 2009 at 11:22 AM, Terry Reedy wrote: > Mike wrote: > > >> >> On Thu, Jun 4, 2009 at 4:40 AM, Terry Reedy > tjre...@udel.edu>> wrote: >> >>Mike wrote: >> >>Hello, >> >>I'm writing an application that needs to fetch a json file from >>a webserver. I'm writ

Re: unittest - what is the best way to reuse test data?

Mike wrote: On Thu, Jun 4, 2009 at 4:40 AM, Terry Reedy > wrote: Mike wrote: Hello, I'm writing an application that needs to fetch a json file from a webserver. I'm writing the tests and have a question: if I have the following m

Re: unittest - what is the best way to reuse test data?

On Thu, Jun 4, 2009 at 4:40 AM, Terry Reedy wrote: > Mike wrote: > >> Hello, >> >> I'm writing an application that needs to fetch a json file from a >> webserver. I'm writing the tests and have a question: >> >> if I have the following methods: >> >> def test_headers(self): >>headers = libary

Re: unittest - what is the best way to reuse test data?

Mike wrote: Hello, I'm writing an application that needs to fetch a json file from a webserver. I'm writing the tests and have a question: if I have the following methods: def test_headers(self): headers = libary.get_data(data) check header status With no json experience specifical

unittest - what is the best way to reuse test data?

Hello, I'm writing an application that needs to fetch a json file from a webserver. I'm writing the tests and have a question: if I have the following methods: def test_headers(self): headers = libary.get_data(data) check header status def test_get_info info = libary.get_info(libary

Re: UnitTest break on failure

Python, 1. go ahead, if a failure is occurred. 2. stop, if an error is occurred? Well, each test should be independent, so generally you are talking about multiple tests. If you really want a test to see if you get through a sequence in a single test: import unittest ... class MyTest

Re: UnitTest break on failure

On Tue, Feb 10, 2009 at 11:48 AM, Qian Xu wrote: > self.assertEquals(testMethod1(), expected_value1); > self.assertEquals(testMethod2(), expected_value2); > > However, if the first test item is failed, no more tests will be executed. > Can I tell Python, > 1. go ahead, if a failure is occurred.

UnitTest break on failure

Hi All, i am writing unit tests and have got a problem: I want to test some code sequence like: self.assertEquals(testMethod1(), expected_value1); self.assertEquals(testMethod2(), expected_value2); However, if the first test item is failed, no more tests will be executed. Can I tell Python, 1

Re: unittest, order of test execution

he order of test execution > > in the unittest? And how to pass values between unit tests? Should I > > modify 'self' in unit test? > > It's OK to run some tests in the same function. > When one of the asserts fails, following the traceback will lead you > str

Re: unittest, order of test execution

> But I was wondering, *should* this test be separated into two unit > tests, one for each function? On the face of it, it looks that's how it > should be done. > > This, however, raises the question: what's the order of test execution > in the unittest? And how to pa

unittest, order of test execution

#x27;: '12:50', 'val': 0.17}] self.assertEqual(valist, valist_ut) vlextr_ut = [0.11, 0.08, 0.57, 0.21, 0.08, 0.66, 0.32, 0.12, 0.47, 0.17] vlextr = ma.extrvalues(valist) self.assertEqual(len(vlextr_ut), len(vlextr)) for (idx, elem) in enumerate(vlextr_ut): self.assertAlmostEqual(elem, vlextr[idx]) But I was wondering, *should* this test be separated into two unit tests, one for each function? On the face of it, it looks that's how it should be done. This, however, raises the question: what's the order of test execution in the unittest? And how to pass values between unit tests? Should I modify 'self' in unit test? Regards, mk -- http://mail.python.org/mailman/listinfo/python-list

Re: unittest exits

On 13 Nov., 20:20, "Chris Rebert" <[EMAIL PROTECTED]> wrote: > try: >     unittest.main() > except SystemExit: >     pass You most probably want this instead: try: unittest.main() except SystemExit, exc: # only exit if tests failed if exc.code: raise --

Re: unittest exits

Alan Baljeu <[EMAIL PROTECTED]> writes: > When I call unittest.main(), it invokes sys.exit(). I would like to > run tests without exiting. How can I? Use a ‘TestRunner’ instance, instead of ‘main()’. -- \ “If you go flying back through time and you see somebody else | `\ flying forwa

Re: unittest exits

On Thu, Nov 13, 2008 at 11:01 AM, Alan Baljeu <[EMAIL PROTECTED]> wrote: > When I call unittest.main(), it invokes sys.exit(). I would like to run > tests without exiting. How can I? There's probably a better way that stops it from trying to exit in the first place, but here's a quick kludge:

unittest exits

When I call unittest.main(), it invokes sys.exit(). I would like to run tests without exiting. How can I? Alan Baljeu __ Instant Messaging, free SMS, sharing photos and more... Try the new Yahoo! Canada Messenger at http

Re: Unittest - adding a doctest suite to unittest.main

Duncan Booth <[EMAIL PROTECTED]> writes: > Create a function named test_suite which creates a test suite > containing all your tests including the doctests. Pass that to main > as the defaultTest argument. Better to name it ‘suite’, so that its name doesn't match the default search for individual

Re: Unittest - adding a doctest suite to unittest.main

On 14 Oct, 16:09, Duncan Booth <[EMAIL PROTECTED]> wrote: > Create a function named test_suite which creates a test suite containing > all your tests including the doctests. Pass that to main as the defaultTest > argument. Ah, thanks. I see now - a suite is itself a test. That makes sense. But ho

Re: Unittest - adding a doctest suite to unittest.main

Paul Moore <[EMAIL PROTECTED]> wrote: > Just before I start diving into the gory details, have I missed a > simple way of adding an additional doctest.DocFileSuite to > unittest.main? Create a function named test_suite which creates a test suite containing all your tests including the doctests.

Unittest - adding a doctest suite to unittest.main

My normal testing consists of a tests.py script using unittest, with the basic if __name__ == '__main__': unittest.main() incantation to get things going. But I now want to incorporate some other tests (specifically, a text file containing doctests) and I find that there is

Re: [unittest] Run setUp only once

;>I have a number of conceptually separate tests that nevertheless need >>>>>>a common, complicated and expensive setup. >>>>>> >>>>>>Unfortunately, unittest runs the setUp method once for each defined >>>>>>test, even if th

Re: [unittest] Run setUp only once

s: >>>> On Tue, 29 Jul 2008 16:35:55 +0200, Nikolaus Rath <[EMAIL PROTECTED]> >>>> wrote: >>>>>Hello, >>>>> >>>>>I have a number of conceptually separate tests that nevertheless need >>>>>a common, complicated

Re: [unittest] Run setUp only once

In article <[EMAIL PROTECTED]>, Nikolaus Rath <[EMAIL PROTECTED]> wrote: > But at least this variation doesn't work, because unittest apparently > also creates two separate TwoTests instances for the two tests. Isn't > there some way to convince unittest to reuse

Re: [unittest] Run setUp only once

Jul 2008 16:35:55 +0200, Nikolaus Rath <[EMAIL PROTECTED]> wrote: Hello, I have a number of conceptually separate tests that nevertheless need a common, complicated and expensive setup. Unfortunately, unittest runs the setUp method once for each defined test, even if they're part of t

Re: [unittest] Run setUp only once

te: >>>>Hello, >>>> >>>>I have a number of conceptually separate tests that nevertheless need >>>>a common, complicated and expensive setup. >>>> >>>>Unfortunately, unittest runs the setUp method once for each defined >>

Re: [unittest] Run setUp only once

less need a common, complicated and expensive setup. Unfortunately, unittest runs the setUp method once for each defined test, even if they're part of the same class as in class TwoTests(unittest.TestCase): def setUp(self): # do something very time consuming def testO

Re: [unittest] Run setUp only once

Jean-Paul Calderone <[EMAIL PROTECTED]> writes: > On Tue, 29 Jul 2008 16:35:55 +0200, Nikolaus Rath <[EMAIL PROTECTED]> wrote: >>Hello, >> >>I have a number of conceptually separate tests that nevertheless need >>a common, complicated and expensive setup

Re: [unittest] Run setUp only once

On Tue, 29 Jul 2008 16:35:55 +0200, Nikolaus Rath <[EMAIL PROTECTED]> wrote: Hello, I have a number of conceptually separate tests that nevertheless need a common, complicated and expensive setup. Unfortunately, unittest runs the setUp method once for each defined test, even if they'

[unittest] Run setUp only once

Hello, I have a number of conceptually separate tests that nevertheless need a common, complicated and expensive setup. Unfortunately, unittest runs the setUp method once for each defined test, even if they're part of the same class as in class TwoTests(unittest.TestCase): def setUp

Re: unittest: Calling tests in liner number order

On 2008-05-24, Fuzzyman <[EMAIL PROTECTED]> wrote: > > A worthwhile question for the OP - your patch seems fairly simple. Is > it easy for you to extend unittest for your own testing needs by > subclassing? I've been ill the last days, but I will look into this possibil

Re: unittest: Calling tests in liner number order

Diez B. Roggisch <[EMAIL PROTECTED]> wrote: >I don't see this as something that can be solved by ordering tests - >*especially* not on a per-method-level as the OP suggested, because I >tend to have test suites that span several files. unittest already runs multiple test sui

RE: unittest: Calling tests in liner number order

> On Behalf Of Roy Smith > You could have a bunch of tests of increasing complexity. > The first bunch of tests all run in a few seconds and test > some basic functionality. From experience, you also know > that these are the tests that are most likely to fail as you > port to a new environme

Re: unittest: Calling tests in liner number order

In fact, from a protocol point of view, some of the types really do depend on each other. We send counted strings, for example, so we can't send a string until we know how to send an int (for the string length). If the first test that fails is the string test, I know right off that the problem

Re: unittest: Calling tests in liner number order

Here's an example of why *running* tests in order can make sense. You could have a bunch of tests of increasing complexity. The first bunch of tests all run in a few seconds and test some basic functionality. From experience, you also know that these are the tests that are most likely to f

Re: unittest: Calling tests in liner number order

ncies between his tests.  Maybe he > just wants them run in order because it's easier to understand the output > in a certain order. No, we're pointing out that running tests in a specific order can introduce hidden dependencies without you being aware of it. Whilst this is already the

Re: unittest: Calling tests in liner number order

"Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > I agree that tests should not depend on each other, but sometimes it's > > still useful to have the tests run in a certain order for reporting > > purposes. > > Then sort your report. Seriously. A test-outpt shoud be in a way that > delimits in

Re: unittest: Calling tests in liner number order

In article <[EMAIL PROTECTED]>, John Roth <[EMAIL PROTECTED]> wrote: > I really don't care what the OP does in his own projects. My objection > is that, if it goes into the standard library, is that it passes a > signal that it's good practice to allow dependencies between tests. It > most defin

Re: unittest: Calling tests in liner number order

On May 24, 7:22 am, André <[EMAIL PROTECTED]> wrote: > > I can't relate to anyone that want to oppose a change that would give > more freedom to a programmer. > > André Well, you can already do that. Or anything else you want. It's not all that difficult to change

Re: unittest: Calling tests in liner number order

Roy Smith schrieb: In article <[EMAIL PROTECTED]>, Fuzzyman <[EMAIL PROTECTED]> wrote: Also, like others, I have had wonderful experiences of trying to track down test failures that depend on the order that tests run in. Having interdependencies between tests is a recipe for madness... I ag

Re: unittest: Calling tests in liner number order

On May 24, 3:57 pm, Roy Smith <[EMAIL PROTECTED]> wrote: > In article > <[EMAIL PROTECTED]>, > >  Fuzzyman <[EMAIL PROTECTED]> wrote: > > Whilst I understand your point, I think the danger is that you end up > > with hidden dependencies on the test order - which you're not aware of > > and that the

Re: unittest: Calling tests in liner number order

In article <[EMAIL PROTECTED]>, Fuzzyman <[EMAIL PROTECTED]> wrote: > Whilst I understand your point, I think the danger is that you end up > with hidden dependencies on the test order - which you're not aware of > and that the tests never expose. Well, yes. But, this is no worse than the curr

Re: unittest: Calling tests in liner number order

>I can't relate to anyone that want to oppose a change that would give >more freedom to a programmer. While in general I agree with this.. I think in the case of python part of it's base philosophy seems to be a tendency to encourage a single way of doing things, and create a path of least resista

Re: unittest: Calling tests in liner number order

expose. Certainly layout your tests in a logical order within the file, but I think you risk potential problems by controlling the order they are run in. Other frameworks specifically provide test order randomizers for this very reason. A worthwhile question for the OP - your patch seems fairly simpl

Re: unittest: Calling tests in liner number order

In article <[EMAIL PROTECTED]>, Fuzzyman <[EMAIL PROTECTED]> wrote: > Also, like others, I have had wonderful experiences of trying to track > down test failures that depend on the order that tests run in. Having > interdependencies between tests is a recipe for madness... I agree that tests sh

Re: unittest: Calling tests in liner number order

On May 23, 10:36 am, Antoon Pardon <[EMAIL PROTECTED]> wrote: > Some time ago I asked whether is would be possible that unittest would > perform the test in order of appearence in the file. > > The answers seemed to be negative. Since I really would like this > behaviour

Re: unittest: Calling tests in liner number order

On May 24, 10:12 am, Roy Smith <[EMAIL PROTECTED]> wrote: > In article > <[EMAIL PROTECTED]>, > John Roth <[EMAIL PROTECTED]> wrote: > > > > Does the following patch has a chance of being introduced in the > > > standard python distribution? > > > I certainly hope not! > > I think you're being ove

Re: unittest: Calling tests in liner number order

In article <[EMAIL PROTECTED]>, John Roth <[EMAIL PROTECTED]> wrote: > > Does the following patch has a chance of being introduced in the > > standard python distribution? > > I certainly hope not! I think you're being overly negative here. Antoon went to the trouble to read the sources and

Re: unittest: Calling tests in liner number order

Antoon Pardon <[EMAIL PROTECTED]> writes: > The answers seemed to be negative. Since I really would like this > behaviour I didn't see you explain *why* you think this behaviour is desirable. You've already had responses that explained why it leaves you open to more bugs when code only works if t

<    1   2   3   4   5   6   >