Metatest 0.1.0

[Kay Schluehr]

On Sep 18, 3:55 pm, Jonathan Fine <jf... at pytex.org> wrote:
> Hello
>
> This announcement also appears on the Metatest web sitehttp://metatest.sourceforge.net
>
> ===
> *** Metatest - a Python test framework
>
> Metatest is a simple and elegant Python framework for writing tests.
>
> Metatest is mostly about writing tests and by design is not tied to any
> particular test runner. Hence the name.
>
> Here's how to write some tests using Metatest. We can think of the tests
> as an executable specification.
>
>      from metatest.py.mymod import plus, Point
>
>      # Function plus adds two numbers.
>      plus(2, 2) == 4
>      plus(2, '', _ex=TypeError)
>
>      # Class Point represent a point in the plane.
>      p = Point(2, 5)
>      p.x == 2
>      p.y == 5
>      p.area == 10
>
> And here's one way to run them.
>
>      if __name__ == '__main__':
>          import metatest
>          metatest.run()
>
> It's not hard to write an adapter that will run these tests in a
> different test runner framework.
>
> We gave a talk about Metatest at PyCon UK 2007 and here are the slides
> (HTML).
>      http://www.pyconuk.org
>      http://metatest.sourceforge.net/doc/pyconuk2007/metatest.html
>
> Please visit Sourceforge to download Metatest.
>      http://sourceforge.net/project/showfiles.php?group_id=204046
>
> --
> Jonathan Fine

>From the HTML slides:

   Assertion tests are easy to write but report and run poorly.

I tend to think this is a prejudice that leads to ever more ways to
write tests perform test discoveries, invent test frameworks etc.

When I thought about organizing my tests for EasyExtend I was seeking
for a strategy being adapted to my own behaviour. The very first step
I made when creating a new language, modifying a grammar rule,
changing the Transformer etc. was starting an interactive shell and
typing some commands. This is just checking out or smoke testing my
application and I wanted to reproduce it. So I recorded the
interactive shell session and replayed it as another shell session. I
enabled to set breakpoints in the logged output and implemented a
command for proceeding the replay.

Then I discovered I actually wrote an interactive test runner. I don't
have to care for all the exceptions being thrown in the session and
don't care for cleanups but just assign parts of the session as tests
using assert for getting an overview at the end. The only additonal
command I implemented was raises to capture the side-effect of raising
an exception.

So I'm going to argue here that there isn't anything particular about
writing/coding a test ( planning tests, specifying tests, reviewing a
testspecification etc. are another issue ). Instead you can keep a
seemingly unrelated practice and turn it into a test by a tiny
signification.