[Cosmo-dev] Re: [Scooby-dev] Cosmo/Scooby Merge (Please read and comment)

[Brian Moseley]

On 7/14/06, Mikeal Rogers <mikeal at osafoundation.org> wrote:

> Actually, the separation makes functional testing easier and more
> thorough. The more we can develop testing tools that test each piece
> of the products in isolation the more granular our tests become and
> the faster we can identify problems.

functional testing isn't our problem. unit testing is. with less code
in the product, we have fewer classes to write unit tests for. with no
network layer between the scooby service and the cosmo internal apis,
we have fewer integration tests to write and configurations to verify.

>  From a functional testing perspective we can currently make all the
> same caldav calls to cosmo that scooby makes and in fact build an
> entire suite of tests that verify cosmo is properly responding to
> everything that scooby may want to do, if the merge happens we do
> loose that.

you can still test those same interactions with cosmo. we're not
taking any functionality away from cosmo.

> Less bugs will occur in the scooby client code (because it won't need
> to exist), but if cosmo is still building a public interface for
> those features we're going to see the same bugs and we won't have the
> benefit of the scooby client catching them first, we'd have to wait
> until someone either wrote a huge client emulator that tested the
> interface or some real world client started using the interface.

the same opportunity exists for bugs in the cosmo protocol handling
code. but because there's no scooby client-side protocol handling code
anymore, there won't be any bugs in that code to find and fix and to
write tests for.

we should absolutely write functional tests for all of cosmo's
interfaces. we should make sure there is great coverage for all of
them. we should do this whether or not our calendar ui talks across
one of those interfaces or not.

> New Cosmo developers or new Scooby developers? And why?

both. there will no longer be any distinction between the two. the
only real distinction i see at this point is between front end (dhtml,
js) and back end (java). the overall system will be easier to grok
because there are fewer software layers.