Re: Unit testing a plug-in architecture
Re: Unit testing a plug-in architecture
- Subject: Re: Unit testing a plug-in architecture
- From: Derek Wyatt <email@hidden>
- Date: Thu, 14 Dec 2006 09:25:21 -0500
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...).
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..
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.
If you're concerned with pollution in terms of putting in test
"hooks" then I wouldn't worry about this. I do stuff like this all
the time... as an example, I have a system were the user selects a
ton of stuff and the I act on it, but the engine required to get
everything available for selection and then select it is outside the
scope of the test, so I have a hook in there that, if environment
variable X exists, then use the contents of that variable as the
selection results. I can then bypass the entire selection module
(which is really quite complex) and just unit test the section of
code I want.
That's not pollution -- that's just good separation, in my opinion.
Regs,
D
On 14-Dec-06, at 9:06 AM, leenoori wrote:
I have a project with unit tests and the following structure:
- Frameworks + unit tests for framework in separate bundles (one
for each framework)
- Application + unit tests for application in separate bundle
This approach is great because it allows me to keep my tests
entirely separate from my code, but always test the exact same code
that ships to the customers.
- The framework case is easy and clean: the test runner loads the
test framework, the framework to be tested, and the test bundle
into memory and runs the tests.
- The application is also easy and almost as clean: the application
runs, I inject the test framework and the bundle, and the tests run.
But I am not sure how to add unit tests for plug-ins that get
loaded into the application. The problem is that I am not sure how
I can maintain the clean separation between code (in the plug-in)
and tests (in a separate bundle). I can't just inject the test
bundles into the application because I don't know which plug-ins
are going to be enabled at the time the tests start running.
I am beginning to think that I may have to "pollute" my plug-ins
with test-related code; or rather, pollute the code in my
application that is responsible for loading plug-ins. Basically, I
would have to add a check for the presence of a test bundle for a
plug-in when it loads that plug-in, and if and only if the test
framework has been loaded into memory, explicitly run the tests for
that bundle.
Is there a cleaner, more elegant way?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
_______________________________________________
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