http://qs321.pair.com?node_id=538690


in reply to Architecting a testing framework for an API

I am trying to come up with a way to build a framework that will let developers code and unit test their yet-to-be-written modules to extend the web application without having to use the actual API code (except for integration testing) and without apache/mod_perl.

That sounds like you want mocks/fakes/stubs here. Take a look at some of the Test Double patterns.

I'm having a hard time trying to figure out is at a high level, how to structure this test framework in such a way that there's not a bunch of code duplication.

Can you give examples of the kind of duplication that you're getting? What's stopping you factoring it out?

  • Comment on Re: Architecting a testing framework for an API

Replies are listed 'Best First'.
Re^2: Architecting a testing framework for an API
by mp (Deacon) on Mar 23, 2006 at 22:27 UTC
    Thank you for the link. The Patterns of xUnit Test Automation site is very helpful in thinking about all of this and is not a site I had seen before.

    I don't have a lot of duplication yet, since this project is still in the early stages of development, but I am expecting there to be quite a bit of "test fixture setup" that is repeated from one test to the next (mainly setup of mock objects or subroutine overrides), possibly with variations in the setup data between tests. I think you're right, though, this will be something that can be factored out.

      I am expecting there to be quite a bit of "test fixture setup" that is repeated from one test to the next (mainly setup of mock objects or subroutine overrides), possibly with variations in the setup data between tests.

      Ah. Then this is stuff that Test::Class can help with. You can stick all your repeated fixture setup in a (wittily named) :setup method. You can specialise fixtures with subclassing. That said - wait until you get the duplication before you factor it out would be my advice.