[Grok-dev] Re: Easier test setup with new grok.testing

[Uli Fouquet]

Hi there,

Martijn Faassen wrote:

> > import grok.testing
> > test_suite = grok.grok_tests('cave')
> 
> This would indeed be nice.

No problem. @Luciano: I assume grok.grok_doctests() will be an alias for
grok.testing.grok_doctests() then. So you can use the namespace.


> Agreed, down with the 'main' cruft, let's just use the bin/test 
> testrunner for this and not even mention this cruft in the 
> documentation. It's mostly just cargo cult code people carry over. Get 
> rid of it, please!

It's still not implemented, so no chance to get rid of it ;-)


> Question: what about ftests? You talk about tests, but ftests are run 
> separately by the ftests runner I understand. Is this a misunderstanding 
> and do ftests just work?

Yes, they work fine. As Theuni already told, it is mainly a question of
finding tests, not running them.

> Let's talk a bit about control though. One thing I do very often with 
> doctests is define a bunch of globs to pass in, variables that are 
> available globally. Is there a way to do this with the current code? 

The globs are an attribute of a testsetup instance. You can set it as
you like and they can also be passed as kwarg to the constructor.

A catch-all registerer like::

  grok.register_doctests('cave', globs={'sync': sync})

is therefore very easy to do.

This also applies to setup and teardown funcs.

I will, however, have a look at the ZODB tests to see, what complex
cases can arise.

> Ideas? It might be nice if we could state what globs we want to use in 
> the doctest itself. That makes me think we could simply import them:
> 
>    >>> from mypackage.tests import myhelper
> 
> That might be actually clearer than the use of globs as it doesn't 
> introduce any special casing at all. Any reason why this wouldn't work?

I'm not sure, whether I understand correctly. Are you talking about
avoiding `globs` at all (at test registration time)?

Kind regards,

-- 
Uli