Global hooks that run before / after every test?

75 views
Skip to first unread message

Messenger

unread,
Jul 8, 2011, 3:10:27 PM7/8/11
to Igloo-testing
Just discovered the library and I am very pleased with it. I was
looking for some functionality like cppunit has where you can add
custom TestListeners to the test runner and do stuff before and after
every single test. I am looking for some direction on where I can
shoehorn that into this framework.

Thanks!

Joakim Karlsson

unread,
Jul 8, 2011, 3:55:35 PM7/8/11
to Igloo-testing
Thanks for the feedback!

The closest thing we have at the moment are the SetUp/TearDown methods
that get called before/after each spec.

I don't think it would be too hard to implement something similar to
cppunit, though.

We ought to be able to supply a way to register for callbacks when:
* Before/after a test run
* Before/after all specs in a context is executed
* Before/after a spec is executed
* When a spec fails/succeeds.

That would pretty much mimic cppunit. Are there any more hooks that
would be of interest to you?

Regards,
Joakim

Messenger

unread,
Jul 11, 2011, 10:54:42 AM7/11/11
to Igloo-testing
That sounds good for me. I just wonder how to make it play nice with
TestRunner::RunAllTests(). Maybe have some type of
TestRunner::AddListener() function or something?

On Jul 8, 2:55 pm, Joakim Karlsson <joakim.h.karls...@gmail.com>
wrote:

Joakim Karlsson

unread,
Jul 11, 2011, 12:32:35 PM7/11/11
to Igloo-testing
I've been thinking about that myself.

We can either go with the static method route already started, or we
could offer a new way to run tests where we instantiate a TestRunner,
add custom listeners and custom output classes, and then tell it to
run all tests.

Something like:

TestRunner runner;
runner.AddListener(...);
runner.AddOutputter(...);
runner.RunAllTests();

Going with instance methods might make it easier to test Igloo
internally.

/Joakim

Joakim Karlsson

unread,
Jul 11, 2011, 12:39:27 PM7/11/11
to Igloo-testing
Could you share some more insights on how you would use a custom
TestListener?

I see two scenarios, one where we have a TestListener that is passive
and does not interfere with the test run, and one where the
TestListener might do things like stop the test run all together.

The first scenario is pretty straight forward, the other might turn
out to be too complex to make sense of.

/Joakim

On Jul 8, 9:10 pm, Messenger <mcelw...@msoe.edu> wrote:

Messenger

unread,
Jul 11, 2011, 2:02:27 PM7/11/11
to Igloo-testing
The current way I am using it with cppunit is to clear out a bunch of
static state that my system has. Everything in my system interfaces
through a static Factory class to build primitives that communicate
with IPC and such. I want to ensure that the TestFactory double is
created at the beginning of every spec and doesn't maintain any old
state from previous specs. Here is my cppunit one:

class Initializer : public CPPUNIT_NS::TestListener
{
private:
TestFactory* factory;

public:
void startTest( CPPUNIT_NS::Test *test )
{
factory = new TestFactory();
CoreData::LocalFactory::Clear();
}

void endTest( CPPUNIT_NS::Test *test )
{
delete factory;
}
};



On Jul 11, 11:39 am, Joakim Karlsson <joakim.h.karls...@gmail.com>
wrote:

Mike Long

unread,
Jul 12, 2011, 7:31:04 AM7/12/11
to igloo-...@googlegroups.com
Hi,

I just thought I'd give my 2 cents.  I quite like the approach that the google test framework does this.


Best regards,
Mike

Joakim Karlsson

unread,
Jul 12, 2011, 10:26:09 AM7/12/11
to igloo-...@googlegroups.com
Thanks, Mike.

The static same test SetUp/TearDown is on my to do list.

In the case of the global environment object, how is that accessed
from the tests? Is something injected to the tests, or is the
environment global?

/Joakim

Mike Long

unread,
Jul 12, 2011, 10:52:56 AM7/12/11
to igloo-...@googlegroups.com
What you do is define a subclass of the environment class and pass it to the framework before running all the tests.  There is an example in the wiki section that shows how to make it a global variable, but you can also inject it into test fixtures through the constructor.

Mike
Reply all
Reply to author
Forward
0 new messages