portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: "Merging" my branch
Date Tue, 18 May 2004 21:22:39 GMT

On May 18, 2004, at 1:51 PM, Scott T Weaver wrote:
>>
>> 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.
> These would be integration/sanity tests and SHOULD NOT run 
> automatically
> 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.
>
Well these tests do capture bugs quite often, especially between 
back-end databases.
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.

>> I do also see the need for basic unit tests with mock objects.
> These are actual unit tests.
>
No need to get pedantic :-)
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.
>
>>
>>>
>>> 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
>>>
>> I think Im guilty of above on occasion
>> 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message