[TIP] Sclara is a Python testing DSL
alfredodeza at gmail.com
Mon Mar 26 04:08:29 PDT 2012
On Mon, Mar 26, 2012 at 3:56 AM, <Chris.Wesseling at cwi.nl> wrote:
> On 2012-03-24T16:00:06-0500, John MacKenzie wrote:
> > http://github.com/198d/sclara
> > There are failures in both as a demonstration of how this interacts with
> > TestRunner. The first one proves mainly that this is just Python; if you
> > use one of the provided runners you can execute your test files with the
> > Python interpreter (a big goal after looking at a tool like komira for
> > sort of thing). The latter demonstrates that a nose plugin is possible
> > probably implies that a py.test plugin is doable to.
> Could you point me to "komira"? Your e-mail turns up as the only
> relevant hit using my search-fu.
Konira is a Testing DSL framework  that I started working on about a
year and a half ago. It
is not valid Python (hence the DSL connotation) but it is translated to it
when tests are run
via de included Test Runner or with the py.test  plugin for it.
The problem that I see these solutions (including Konira) bring to the
table is that they all try to
create a flexible, descriptive and terse domain for writing tests, and
while some of them have a
significant gain over current testing standards, they fail when the
complexity goes beyond
asserting something that has a nice description.
It might be heretic to raise this in a testing list for Python, but I also
believe that the Python community
is not as pro-innovation in the testing environment as other communities
are, which is detrimental to the fact
that there are a few people who don't like the standard testing framework
and are looking forwards to an
> > Beyond sclara, I'm considering the idea that, more than a testing
> > framework, I stumbled on an interesting pattern for building generic DSLs
> > in Python (more on this soon, hopefully).
> > Thoughts?
> I started reading the tests, to see if the DSL provides the clarity we
> need in
> this domain:
> examples/test_sclara.py line 14:
> with test('does not have access to inner setup context') as context:
> except AttributeError:
> Will this fail if no AttributeError is thrown?
> And line 45:
> with test('has access to inner setup context') as context:
> assert context.foo == 'bar'
> with test('has access to outer setup context') as context:
> assert context.bar == 'foo'
> Shouldn't "inner" and "outer" be swapped here?
> The outer setup adds foo and baz attributes.
> The inner setup adds the bar attribute to the context and changes the baz
> What I see as a pitfall for users with this idiom, is that it might invite
> breaking isolation.
> Interesting, though.
> Chris Wesseling
> Centrum Wiskunde & Informatica (CWI)
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the testing-in-python