On 8/28/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 8/22/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> > When I was fixing tests failing in the py3k branch, I found the number
> > duplicate failures annoying. Often, a single bug, in an important
> > method or function, caused a large number of testcase to fail. So, I
> > thought of a simple mechanism for avoiding such cascading failures.
> >
> > My solution is to add a notion of dependency to testcases. A typical
> > usage would look like this:
> >
> > @depends('test_getvalue')
> > def test_writelines(self):
> > ...
> > memio.writelines([buf] * 100)
> > self.assertEqual(memio.getvalue(), buf * 100)
> > ...
>
> This definitely seems like a neat idea. Some thoughts:
>
> * How do you deal with dependencies that cross test modules? Say
> test A depends on test B, how do we know whether it's worthwhile
> to run A if B hasn't been run yet? It looks like you run the test
> anyway (I haven't studied the code closely), but that doesn't
> seem ideal.
I am not sure what you mean by "test modules". Do you mean module in
the Python sense, or like a test-case class?
> * This might be implemented in the wrong place. For example, the [x
> for x in dir(self) if x.startswith('test')] you do is most certainly
> better-placed in a custom TestLoader implementation.
That certainly is a good suggestion. I am not sure yet how I will
implement my idea in the unittest module. However, I pretty sure that
it will be quite different from my prototype.
> But despite that, I think it's a cool idea and worth pursuing. Could
> you set up a branch (probably of py3k) so we can see how this plays
> out in the large?
Sure. I need to finish merging pickle and cPickle for Py3k before
tackling this project, though.
-- Alexandre
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
