Am 06.01.2012 12:44, schrieb Peter Otten:
[running unit tests in the order of their definition]
class Loader(unittest.TestLoader):
def getTestCaseNames(self, testCaseClass):
"""Return a sequence of method names found within testCaseClass
sorted by co_firstlineno.
"
In article ,
Lie Ryan wrote:
> >> All serious database has rollback feature when they're available to
> >> quickly revert database state in the setUp/cleanUp phase.
> >
> > I guess MongoDB is not a serious database?
>
> I guess there are always those oddball cases, but if you choose MongoDB
>
Am 10.01.2012 13:31, schrieb Lie Ryan:
While it is possible to replace __dict__ with OrderedDict and it is
possible to reorder the test, those are not his original problem, and
the optimal solution to his original problem differs from the optimal
solution to what he think he will need.
Oh, and
On Tue, 2012-01-10 at 09:05 -0500, Roy Smith wrote:
>
> I guess MongoDB is not a serious database?
That's opening up a can of worms ;)
... anyway, cassandra is far better.
Tim
--
http://mail.python.org/mailman/listinfo/python-list
On 01/11/2012 01:05 AM, Roy Smith wrote:
In article,
Lie Ryan wrote:
On 01/10/2012 12:05 PM, Roy Smith wrote:
Somewhat more seriously, let's say you wanted to do test queries against
a database with 100 million records in it. You could rebuild the
database from scratch for each test, but d
In article ,
Lie Ryan wrote:
> On 01/10/2012 12:05 PM, Roy Smith wrote:
> > Somewhat more seriously, let's say you wanted to do test queries against
> > a database with 100 million records in it. You could rebuild the
> > database from scratch for each test, but doing so might take hours per
>
On 01/10/2012 03:59 AM, Ulrich Eckhardt wrote:
There is another dependency and that I'd call a logical dependency. This
occurs when e.g. test X tests for an API presence and test Y tests the
API behaviour. In other words, Y has no chance to succeed if X already
failed. Unfortunately, there is n
On 01/10/2012 12:16 AM, Ulrich Eckhardt wrote:
Am 09.01.2012 13:10, schrieb Lie Ryan:
I was just suggesting that what the OP thinks he wants is quite
likely not what he actually wants.
Rest assured that the OP has a rather good idea of what he wants and
why, the latter being something you don'
On 01/10/2012 12:05 PM, Roy Smith wrote:
Somewhat more seriously, let's say you wanted to do test queries against
a database with 100 million records in it. You could rebuild the
database from scratch for each test, but doing so might take hours per
test. Sometimes, real life is just*so* incon
On 1/9/2012 8:05 PM, Roy Smith wrote:
In article<11jrt8-l32@satorlaser.homedns.org>,
Ulrich Eckhardt wrote:
Some people advocate that the test framework should
intentionally randomize the order, to flush out inter-test dependencies
that the author didn't realize existed (or intend).
If
In article <11jrt8-l32@satorlaser.homedns.org>,
Ulrich Eckhardt wrote:
> > Some people advocate that the test framework should
> > intentionally randomize the order, to flush out inter-test dependencies
> > that the author didn't realize existed (or intend).
>
> If you now
> happen to infl
On Mon, Jan 9, 2012 at 9:59 AM, Ulrich Eckhardt
wrote:
> There is another dependency and that I'd call a logical dependency. This
> occurs when e.g. test X tests for an API presence and test Y tests the API
> behaviour. In other words, Y has no chance to succeed if X already failed.
> Unfortunatel
Am 09.01.2012 15:35, schrieb Roy Smith:
The classic unittest philosophy says that tests should be independent of
each other, which means they should be able to be run in arbitrary
order. Some people advocate that the test framework should
intentionally randomize the order, to flush out inter-tes
On 2012-01-09, Roy Smith wrote:
> If somebody (i.e. the classic "consenting adult" of the Python
> world) wants to take advantage of that to write a test suite
> where the tests *do* depend on each other, and have to be run
> in a certain order, there's nothing wrong with that. As long
> as they
In article ,
Ian Kelly wrote:
> Randomizing the order is not a bad idea, but you also need to be able
> to run the tests in a consistent order, from a specific random seed.
> In the real world, test conflicts and dependencies do happen, and if
> we observe a failure, make a change, rerun the tes
Am 09.01.2012 13:10, schrieb Lie Ryan:
I was just suggesting that what the OP thinks he wants is quite
likely not what he actually wants.
Rest assured that the OP has a rather good idea of what he wants and
why, the latter being something you don't know, because he never
bothered to explain
On 01/09/2012 09:03 AM, Eelco wrote:
i havnt read every post in great detail, but it doesnt seem like your
actual question has been answered, so ill give it a try.
AFAIK, changing __dict__ to be an ordereddict is fundamentally
impossible in python 2. __dict__ is a builtin language construct
hard
On Jan 7, 2:06 am, Ian Kelly wrote:
> wrote:
> > Nonetheless, I'm still wondering if I could somehow replace the dict with an
> > OrderedDict.
>
> In Python 3, yes. This is pretty much the entire use case for the new
> __prepare__ method of metaclasses. See the "OrderedClass" example[...]
This
i havnt read every post in great detail, but it doesnt seem like your
actual question has been answered, so ill give it a try.
AFAIK, changing __dict__ to be an ordereddict is fundamentally
impossible in python 2. __dict__ is a builtin language construct
hardcoded into the C API. There is no way t
On Fri, Jan 6, 2012 at 5:49 PM, Steven D'Aprano
wrote:
> In the real world, test conflicts and dependencies are bugs in your test
> suite that should be fixed, like any other bug in code. The fact that it
> is test code that is failing is irrelevant.
I agree 100%, but none of that changes my poin
On 01/07/2012 11:49 AM, Steven D'Aprano wrote:
You may not be able to run tests*simultaneously*, due to clashes
involving external resources, but you should be able to run them in
random order.
tests that involves external resources should be mocked, although there
are always a few external re
On Fri, 06 Jan 2012 10:20:28 -0700, Ian Kelly wrote:
> On Fri, Jan 6, 2012 at 10:01 AM, Lie Ryan wrote:
>> That unittest executes its tests in alphabetical order is
>> implementation detail for a very good reason, and good unittest
>> practice dictates that execution order should never be defined
On Sat, 07 Jan 2012 04:01:44 +1100, Lie Ryan wrote:
> On 01/07/2012 12:36 AM, Ulrich Eckhardt wrote:
>> True, perhaps, but doing it this way would be more fun and easier
>> reusable in other cases where the default order is not desirable. I can
>> also go and name the test functions test_000 to te
On 6 January 2012 13:40, Ulrich Eckhardt
wrote:
> Am 06.01.2012 12:44, schrieb Peter Otten:
>
>> Alternatively you can write your own test loader:
>
> [...CODE...]
>
> Well, actually you just did that for me and it works! ;)
>
>
> Nonetheless, I'm still wondering if I could somehow replace the dic
On 6 January 2012 11:44, Peter Otten <__pete...@web.de> wrote:
> class Loader(unittest.TestLoader):
> def getTestCaseNames(self, testCaseClass):
> """Return a sequence of method names found within testCaseClass
> sorted by co_firstlineno.
> """
That's a clever trick!
--
A
On 01/07/2012 04:20 AM, Ian Kelly wrote:
On Fri, Jan 6, 2012 at 10:01 AM, Lie Ryan wrote:
That unittest executes its tests in alphabetical order is implementation
detail for a very good reason, and good unittest practice dictates that
execution order should never be defined (some even argued th
On Fri, Jan 6, 2012 at 10:01 AM, Lie Ryan wrote:
> That unittest executes its tests in alphabetical order is implementation
> detail for a very good reason, and good unittest practice dictates that
> execution order should never be defined (some even argued that the execution
> order should be ran
On 01/07/2012 12:36 AM, Ulrich Eckhardt wrote:
Am 06.01.2012 12:43, schrieb Lie Ryan:
On 01/06/2012 08:48 PM, Ulrich Eckhardt wrote:
Hi!
The topic explains pretty much what I'm trying to do under Python
2.7[1]. The reason for this is that I want dir(SomeType) to show the
attributes in the orde
On Fri, Jan 6, 2012 at 9:06 AM, Ian Kelly wrote:
> On Fri, Jan 6, 2012 at 6:40 AM, Ulrich Eckhardt
> wrote:
>> Nonetheless, I'm still wondering if I could somehow replace the dict with an
>> OrderedDict.
>
> In Python 3, yes. This is pretty much the entire use case for the new
> __prepare__ meth
On Fri, Jan 6, 2012 at 6:40 AM, Ulrich Eckhardt
wrote:
> Nonetheless, I'm still wondering if I could somehow replace the dict with an
> OrderedDict.
In Python 3, yes. This is pretty much the entire use case for the new
__prepare__ method of metaclasses. See the "OrderedClass" example at:
http:/
Ulrich Eckhardt wrote:
Hi!
The topic explains pretty much what I'm trying to do under Python
2.7[1]. The reason for this is that I want dir(SomeType) to show the
attributes in the order of their declaration. This in turn should
hopefully make unittest execute my tests in the order of their
d
Am 06.01.2012 12:44, schrieb Peter Otten:
Alternatively you can write your own test loader:
[...CODE...]
Well, actually you just did that for me and it works! ;)
Nonetheless, I'm still wondering if I could somehow replace the dict
with an OrderedDict.
Thank you!
Uli
--
http://mail.python.
Am 06.01.2012 12:43, schrieb Lie Ryan:
On 01/06/2012 08:48 PM, Ulrich Eckhardt wrote:
Hi!
The topic explains pretty much what I'm trying to do under Python
2.7[1]. The reason for this is that I want dir(SomeType) to show the
attributes in the order of their declaration. This in turn should
hope
Ulrich Eckhardt wrote:
> The topic explains pretty much what I'm trying to do under Python
> 2.7[1]. The reason for this is that I want dir(SomeType) to show the
> attributes in the order of their declaration. This in turn should
> hopefully make unittest execute my tests in the order of their
> d
On 01/06/2012 08:48 PM, Ulrich Eckhardt wrote:
Hi!
The topic explains pretty much what I'm trying to do under Python
2.7[1]. The reason for this is that I want dir(SomeType) to show the
attributes in the order of their declaration. This in turn should
hopefully make unittest execute my tests in
Hi!
The topic explains pretty much what I'm trying to do under Python
2.7[1]. The reason for this is that I want dir(SomeType) to show the
attributes in the order of their declaration. This in turn should
hopefully make unittest execute my tests in the order of their
declaration[2], so that t
36 matches
Mail list logo
