On May 18, 2004, at 1:51 PM, Scott T Weaver wrote:
Well these tests do capture bugs quite often, especially between back-end databases.These would be integration/sanity tests and SHOULD NOT run automatically
What if we formerly defined different kinds of tests, such as unit,
system, component.
I still want the test hitting the database to exist, call them whatever
you want.
These tests would not require mock objects.
at build time. Unit tests should run quickly and many times a day,
integration/sanity should only need to be run once or twice a day.
Im +1 for not running them in everyday building by developers.
But we do need some kind of test automation for integration and system testing.
Perhaps that goes beyond the realm of an open source project with limited resources.
I would not choose the word 'sanity' checks to describe system or integration testing.
Im my mind these kind of tests or much more complex and useful.
No need to get pedantic :-)I do also see the need for basic unit tests with mock objects.These are actual unit tests.
I was just stately it clearly ... since we haven't made the distinction in the past
Not sure if you want to discuss code coverage, because we are no where near that and we don't have the resources to get there Anyway I think you know my feelings on mock objects and that they are only a part of the testing equation
2. NanoQuickDeployer is an evil hack that I created out of sheer
laziness and I ought to be shot, drawn and quartered, flayed, etc. for
introducing it. So, I propose we delete it and just manually assemble
components in jetspeed.groovy. There are two reasons for this:
1. This should alleviate the issue of components starting 2 or 3 times. 2. We can see EVERYTHING that is being assembled into the engine by just looking in one location.
This one has gone back and forth many times
Thinking about how it is now, and after using for a few months, Im
concluding its a lot easier to have one jetspeed.groovy script, instead
of searching all over the class path for scripts
I think that was the original idea
Yep, I cam to the same conclusion, auto-magic is not as kewl as it initially sounds.
I think Im guilty of above on occasion
3. Configuration versus assembly. David Taylor and I have discussed at
length the idea of assembly versus configuration. Assembly is defining
the components we are using within our container and making sure those
components' dependencies are able to be fulfilled. Defining assembly
requires someone with relatively intimate knowledge of Jetspeed 2 and
pico/nano container. Configuration is the defining of the operational
parameters for components that will be assembled. Configuration values
should be primitive and String values and should only represent those
types of values. Configuration values should never expose the "guts"
of your container i.e. it should never ever contain class names.
Example of a good configuration value:
mail.server=mail.foo.bar
template.directory=/WEB-INF/templates
Example of a bad configuration value:
my.implementation.class=org.apache.jetspeed.MyClass
Good examples and clear distinction of configuration and assembly, hold
on to that one ;-)
We can formally define an actual JetspeedConfiguration object that has
getters for all of the expected configuration values as opposed to using
a generic commons Configuration object. This make it easy for us to
drop any implementation of JetspeedConfiguration: properties based,
RDBMS based, JNDI etc.
+1 Interfaces are always good
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
