«

In article <mailman.4588.1326198152.27778.python->,
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
> > test. Sometimes, real life is just*so* inconvenient.
>
> 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?

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

On 01/11/2012 01:05 AM, Roy Smith wrote:
> In article<mailman.4588.1326198152.27778.python->,
> 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
>>> test. Sometimes, real life is just*so* inconvenient.
>>
>> 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
then you already know the consequences that it couldn't be as easily
unit-tested. And in any case, it is generally a bad idea to unittest
with a database that contains 100 million items, that's for performance
testing. So your point is?

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 you know what is optimal in his environment? You really think
you know better what to do based on the little information provided?


> I had said this before and I'm saying it again: the problem is a test
> result displaying issue, not testing order issue.

There are good reasons for not reordering the results of the tests that
would be sacrificed by reordering them afterwards.


If you'd just step off your high horse you might actually learn
something instead of just ****ing people off.

Uli

In article <mailman.4603.1326211045.27778.python->,
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
> then you already know the consequences that it couldn't be as easily
> unit-tested. And in any case, it is generally a bad idea to unittest
> with a database that contains 100 million items, that's for performance
> testing. So your point is?

My point is that in the real world, what is practical and efficient and
sound business is not always what is theoretically correct.

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.
> """
> def first_lineno(name):
> method = getattr(testCaseClass, name)
> return method.im_func.__code__.co_firstlineno
>
> function_names = super(Loader, self).getTestCaseNames(testCaseClass)
> function_names.sort(key=first_lineno)
> return function_names

After using this a bit, it works great. I have up to now only found a
single problem, and that is that with decorated functions it doesn't
even get at the actual line number of the real code, so sorting by that
number doesn't work. An example for this is
"@unittest.expectedFailure(...)".

I can easily ignore this though, just wanted to give this feedback

Thanks again!

Uli