Re: Development Process

Peter Donald wrote:

> Recently I noticed that a few of the changes in ThreadPool/Netserve either 
> broke the unit tests or made the code not work when deployed. I dont mind 
> experimentation but I would prefer that at the end the code at least builds 
> ;) 

+1 - I always ensure (or attempt to ;-) that the code builds after any 
change/refactor.  And that tests pass - if possible.

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.

> I would also prefer that javadocs be in place from the begining for any 
> new code. To ensure this I was thinking about adding in pre-jar checks to 
> ensure that the codebase has sufficient unit test coverage, passes all 
> checkstyle run etc.

Do we want to enforce javadocs strictly - ie on every public method of 
every class?  Some cases may be self-explanatory, eg the case of Monitors.
I would make the checks configurable (in the same way that maven tests 
can be disabled when necessary) - and set to true by default.

> 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?

Cheers






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