Re: Unit testing a plug-in architecture
Re: Unit testing a plug-in architecture
- Subject: Re: Unit testing a plug-in architecture
- From: leenoori <email@hidden>
- Date: Thu, 14 Dec 2006 18:53:58 +0100
El 14/12/2006, a las 15:25, Derek Wyatt escribió:
It's hard to say exactly, but in general one would decouple the two
by requiring there to be a test framework outside of the two that
is responsible for joining the logic (in the spirit of all of the
"unit" test frameworks out there, etc...).
Thanks for the input, Derek.
In other words, tests like this:
- For each plugin X do
- Using the application's plugin load framework, can we load
plugin X
- Using the application's state engine, can we fire the plugin
through it?
- etc etc..
The application doesn't have a framework for loading plug-ins, it
just has a class that is responsible for loading them. Are you
suggesting that this should be split out into a framework so that a
test bundle could directly access it? (Or equivalently, just link
against the app as BUNDLE_LOADER.)
So the test framework is outside of both systems and, if your
application framework is abstracted sufficiently then the amount of
reuse is in the 99% area so there is very little duplication in the
test framework. But if you need your entire app to test any small
feature then you're probably baked.
I dunno how you do it, but this is how I do it. It's really hard
to get an impression of what you're doing because I'm sure your app
is sufficiently complex to make any guess, well... stupid... but it
sounds to me like you've got a situation where your app is lacking
in sufficient separation to write modular tests and in that case,
you might have to pollute, or refactor.
Well, it's an interesting question. The whole point of the plug-in
architecture was that it would enable me to add optional stuff to the
app in a completely modular fashion. In this way, if a user doesn't
want a particular piece of functionality they don't even have to
dedicate memory to it and launch times are quicker. The dependence is
entirely one-way; that is, each plug-in depends on the application
and in fact specifies it as its BUNDLE_LOADER but the application
does not depend on any plug-in in any way and never makes any
reference to any code in any specific plug-in.
So in other words the application and the plug-ins themselves are
highly modular and I believe well compartmentalized, and I did it
this way because I believed it was the best design.
The issue is, how do I keep the unit testing side of things nice and
clean and elegant? I am not sure how I could do what you suggest (get
the test framework to do the joining)... that would require the test
framework to know about the internal details of how the application
loads the plug-ins, so I've just moved the location of the "ugly
pollution" from the application to the framework, but the ugliness is
still there. And I don't really want to modify the testing framework
itself anyway because that would be adding project-specific stuff to
a framework that's intended for general-use.
I'm wondering if what you were getting at was the following kind of
set up between the components:
- Application (contains logic for loading plug-ins)
- Unit tests for application (in separate bundle)
- Plug-ins to be tested
- Unit tests for plug-in (separate bundle for each plug-in)
- "Glue" bundle that manages the running of the plug-in tests
That is, the "glue" bundle would link against the application using
BUNDLE_LOADER, and would therefore be able to use the application's
plug-in management code to get a list of loaded plug-ins, load plug-
in test bundles as necessary and fire off the tests. Seeing as there
is already one bundle being loaded for the application unit tests,
the "glue" may as well be rolled into that one. It's a little bit
nasty but it may work.
Anyway, I'll keep thinking about it and if you have any other ideas
let me know!
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden