Re: [Vala] [RFC] Testing framework improvements

[Julien Peeters <jj peeters gmail com>]

Hi Jan,

Pleased to see you took a look at our work.

2009/8/8 Jan Hudec <bulb ucw cz>

> Hello Julien,
>
> Julien Peeters <jj peeters    > writes:
> > We made work about that in LibGee. We wrote a TestFixture class which
> wraps
> > the TestCase class of GLib.Test namespace and make tests use Vala style
> > coding.
> >
> > Our work in only in the master branch of libgee (see
> tests/testfixture.vala)
> > for the moment. I have planned to improve this little framework and make
> it
> > become an independant library if that will make sense.
>
> I have downloaded libgee and looked at it. Unfortunately it's a different
> from what other unit test libraries call a fixture, because in all those
> libraries, the fixture is re-created for each test case and deleted again
> afterwards.

I am not sure I get you on your remark about the way we manage fixtures. Do
you download code from git master branch ?
I think we should discuss about that on #vala channel. That's would be
easier, isn't it?

It should be possible to convert your fixture to behave that way by making
> the suite a class variable and placing the add_test calls into the class
> constructor.  (The class variables and class constructors are members and
> constructor of the meta-object, so they are separate for each subclass). On
> the other hand the gir-based approach would still make it nicer to use.

Certainly, but once again, I think we achieve the same thing with two
different ways.


> Also now I noticed a problem caused by the generic tests. With explicitly
> created fixtures, you can have generic fixtures and set the types as you
> wish. But the same would not be possible with introspection-based
> construction. So one would instead create subclasses, that would derive
> using
> particular type. And that causes a problem how the runner knows not to
> instantiate the base class -- which leads me to believe the fixture should
> in
> fact be an interface, so the test classes can be derived in whatever way
> one
> needs. It makes a lot of sense in other cases too, e.g. if you want to run
> the same set of tests against multiple implementations of something.

Of course I agree. Generic tests cannot be used with introspection in the
way you describe the problem. But an intermediate choice can certainly be
possible. Using generic tests make possible to factorize a lot of code
especially in generic containers tests and that should ever improve tests
consistence and reliability despite they are a bit more complicated to write
and need to be re-implemented in some specific cases.

I think our both directions are completing and then make code being possibly
factorized.

I will update it when I test that the gir approach is viable.


Great.


> Regards,
> Jan

Best,
Julien.

-- 
Student in electronics and engineering
Institut de Formation des Ingénieurs de Paris-Sud (IFIPS)
Orsay, France
LinkedIn profile : http://www.linkedin.com/in/julienpeeters
Website : http://www.julienpeeters.fr