Classes that write to files, brittleness, and clutter
Posted: Wed Feb 07, 2007 10:22 am
Hi. I'm writing a few classes to act as a sort of plugin scaffolding. One of the classes has to read from a file(which I call the "manifest" file). And in the future one or more classes will either have to write to this file or another one.
I'm not sure if I should use the same file that will be used from the real app code, if I should create and destroy the file on the fly with the setup() and teardown() methods, or if I should just create a separate one for development/testing.
The information the file holds: the name of the plugin; 1 or 0 denoting whether it is enabled; and a list
of optional, comma separated "namespaces".
Another problem will arise when I do my integration tests. The class that actually loads the plugins uses the manifest reader class and then reads the plugin files themselves from the file system. So they need to exist. So for that, should I create a set of dummy plugins just for testing? Actually that's what I've already done, for the plugin loader class, which needs to access real plugin files on the file system, but I don't know if that's the path I should continue on. If creating dummy plugins for testing is ok, should I keep them separate from the real plugins to keep from cluttering up the "real" app space?
In other words I don't think I really want dummy plugin entries in the real manifest file and it would be best I think to not have these test plugins in the release version.
Should I mix them together using the same files and directories and such that the "real" code will use and just remove them with a script when I make the release or should I just mix them in and not worry about it, or should I keep the test files completely separate so that the tests only work on dummy test files?
Write now the tests are using files in the "example_plugins" directory but that may change depending on the answers I get here.
Here's the url to the code: http://radiance.dreamhosters.com/jedPlugin/trunk
Be warned, it's still young and messy and not very pretty but it might help you understand my question more. Thanks.
I'm not sure if I should use the same file that will be used from the real app code, if I should create and destroy the file on the fly with the setup() and teardown() methods, or if I should just create a separate one for development/testing.
The information the file holds: the name of the plugin; 1 or 0 denoting whether it is enabled; and a list
of optional, comma separated "namespaces".
Another problem will arise when I do my integration tests. The class that actually loads the plugins uses the manifest reader class and then reads the plugin files themselves from the file system. So they need to exist. So for that, should I create a set of dummy plugins just for testing? Actually that's what I've already done, for the plugin loader class, which needs to access real plugin files on the file system, but I don't know if that's the path I should continue on. If creating dummy plugins for testing is ok, should I keep them separate from the real plugins to keep from cluttering up the "real" app space?
In other words I don't think I really want dummy plugin entries in the real manifest file and it would be best I think to not have these test plugins in the release version.
Should I mix them together using the same files and directories and such that the "real" code will use and just remove them with a script when I make the release or should I just mix them in and not worry about it, or should I keep the test files completely separate so that the tests only work on dummy test files?
Write now the tests are using files in the "example_plugins" directory but that may change depending on the answers I get here.
Here's the url to the code: http://radiance.dreamhosters.com/jedPlugin/trunk
Be warned, it's still young and messy and not very pretty but it might help you understand my question more. Thanks.