[TIP] alphabetical order in testing

Alfredo Deza alfredodeza at gmail.com
Tue Jan 19 12:41:57 PST 2010

On Tue, Jan 19, 2010 at 3:36 PM, Gary Bernhardt <gary.bernhardt at gmail.com>wrote:

> On Tue, Jan 19, 2010 at 12:26 PM, Alfredo Deza <alfredodeza at gmail.com>
> wrote:
> (snip)
> > Would it be OK to alter the naming in the methods to make sure they are
> run
> > in the order I need to? Even if the naming gets really weird like:
> Never! Extract the required functionality into a separate function and
> have both tests call it. If this is a slow-running system test and
> that shared functionality is too expensive to run for each test, then
> do it in the setup and let the tests rely on that.
> Tests should always work regardless of execution order! :)

Ok good point. It is weird though, to get involved with tests and find that
is done differently (e.g. alphabetical order).

> > Or is there a different/better way to do this? I am thinking something
> like
> > breaking the above example in 2 different classes and creating the
> setUp()
> > and tearDown() methods for each, but wouldn't that be a little redundant?
> If it's truly redundant, you'll be able to merge them without relying
> on test order. If you can't do that, then the existence of two
> different classes is expressing the natural differences in the test
> scenarios.
> If the tests want to be separate, but you force them together by
> making them order-dependent, what you're really doing is trading away
> correctness to gain some terseness. That's dangerous! :)

No, I am jut trying to see what is the best approach. If I need to separate
the tests, this is OK. I just want
to make sure I am not writing code that someone (maybe me?) will read this
code later on and
bang their heads against the screen.

> --
> Gary
> http://blog.extracheese.org

Alfredo Deza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20100119/a48467d5/attachment.htm>

More information about the testing-in-python mailing list