river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: development process
Date Wed, 05 Sep 2007 08:23:04 GMT
Hi John,

John McClain - Sun Microsystems, Inc. wrote:
> Mark Brouwer wrote:
>> Thanks for chipping in Jools,
>> Jools wrote:
> [...]
>>> Every test should have a unit test. JUnit has served me well over the 
>>> years.
> FWIW, in "service land" (e.g. Reggie, Outrigger, etc.) I wouldn't 
> characterize most (any?) of the existing tests as "unit tests", they 
> generally run against complete services (or even multiple services). Not 
> sure how "unit testable" the River services are.
> The other nice thing about writing against the service interfaces is the 
> tests are (generally) still valid after the internals of the service 
> changes.

That is certainly true but setting up a complete environment to run
tests after minor modifications is often a bit labor-intensive.

In hindsight, having learned from many mistakes and without any time
constraints imposed on me I would have often preferred writing the logic
of my services in a way that no Jini concepts such as lease and txn
participation would have crept deep into the code. That would allowed
for easier (unit) testing, which of course doesn't dismiss one from
distributed testing.

In the past I have converted Mahalo, Outrigger and Reggie to JSC
Services for deployment in Seven and due to the fact that in general
there is one huge server class with dozens of inner classes that
represents all server side logic and also all stuff related to
exporting, leases, etc. (starter framework) I had to do a lot of
stripping (of the code I mean).

In the Mahalo and Outrigger case I left most of that stuff intact,
because the JSC Specification introduces no limitation on e.g. using
Landlord, or writing your own transaction participation code, or using a
different persistence store. But in the case of Reggie (to be able to
support the inverted event model) I stripped almost everything except
for the stuff related to what Reggie really does, i.e. registering
services and performing lookups.

The above makes it harder for me to integrate changes from River to
Cheiron (always time consuming 3-way diffs/merges I did to inspect and
integrated the changes between the various JTSK releases) but it works
also the other way around. For example my work on Mahalo for named
transactions (mutual exclusion service) is also harder to migrate back
to River if there was interest in extending the Transaction
Specification due to the way the code is written.

I think all I want to say is that when the contributed services where
written in a way that most of the code was agnostic to e.g. the starter
framework and there would have been a greater separation between some of
the logic and the way these are exposed as Jini concepts that testing
would have been easier as well it would have allowed for easier
integration with more advanced/user friendly deployment platforms.

View raw message