Re: Development Process

On Tue, 2 Sep 2003 10:56 pm, Mauro Talevi wrote:
> As for unit tests - we should decide on the best strategy.
> If some do not pass:
> 0. do not check in the code change at all
> (but sometimes may find it handier to check in and sort out later)
> 1. check in code but comment out unit test
> (perhaps putting a TODO or other markup in the javadoc -
> risk is that they may get lost in the flood)
> 2. leave in so that they can be picked up by gump and/or others
>
> I would be inclined for 1. as a general approach.

My approach would be to nag the mailing list and then check it in regardless 
;) However Gump should pick up any failures - the only exception being 
windows specific ones.

> Do we want to enforce javadocs strictly - ie on every public method of
> every class?  

I prefer it for public code. FWIW I religiously strip out all javadoc from 
private code as it usually gets out of date but for stable toolkit apis it 
doesn't hurt and usually doesn't take long. Along with TDD I tend to document 
as I code and it helps me find ... features :) 

But I guess I am not fussed unless you are checking code into an already 
javadocced class.

> > I was also thinking about setting it up so that at least for the nightly
> > builds (and optionally for user builds) that the components are actually
> > deployed to alive container and some in-contianer tests performed on them
> > there.
>
> +1 but again - make it configurable?

yep - thats definetly something that takes too much time to do every build so 
maybe it could be just run from gump or whatever.

-- 
Cheers,

Peter Donald
---------------------------------------------------
"Wise men don't need advice. Fools don't take it." 
                        -Benjamin Franklin 
--------------------------------------------------- 



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf