• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Unit testing a plug-in architecture
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Unit testing a plug-in architecture
      • From: Derek Wyatt <email@hidden>
References: 
 >Unit testing a plug-in architecture (From: leenoori <email@hidden>)
 >Re: Unit testing a plug-in architecture (From: Derek Wyatt <email@hidden>)

  • Prev by Date: Problems with executable file size
  • Next by Date: Re: Problems with executable file size
  • Previous by thread: Re: Unit testing a plug-in architecture
  • Next by thread: Re: Unit testing a plug-in architecture
  • Index(es):
    • Date
    • Thread