What alpha means

[Howard Lewis Ship <hl...@gmail.com>]

Wanted to go on record on what I think alpha development state means.

It means that the code in a state of flux.  It means new code is
coming in and new ideas are being tried out.  It means we may change
our minds about what was previously added in the same or different
alpha release and may refactor mercilessly.

It doesn't mean that we defer writing tests and documentation! I've
found from painful, painful experience that deferring on either of
these means either a) they never get done or b) it is so horribly
painful that you want to give up software and become a sheep herder.

I've been making every effort to reverse the downward trend on test
code coverage with all the changes I've made to Tapestry in 3.1. Using
EasyMock, the EasyMock class extension, the support for EasyMock built
into HiveMindTestCase, and the Tapestry Creator (instantiates abstract
classes), and just a lot of discipline, it is possible to check in
code that gets 90% - 100% code coverage.  Yes, 100%!

In fact, I'm seeing delivery on the promise that HiveMind makes your
code easier to test. It has been encouraging me to divide my logic
into smaller and smaller units that can be tested individually and
fully.

So I'm making a plea that as new code gets checked in, it comes in
with unit tests.

It does make it a little bit harder when you refactor, you must
refactor the tests as well as the code ... and that's a good thing.
Ensures that things still work after you refactor and otherwise keeps
you honest.  And you might need to refactor the documentation to match
as well.

Meanwhile. I'm hoping to eliminate most of the integration tests (the
TestFoo.xml mock tests) over time. Already there's a good amount of
duplication between them and the new unit tests, and its much, much
faster to test with unit tests. In fact, I expect to spend a good
amount of time filling gaps in the code coverage by writing unit tests
for components (it is components that are largely untested).

Beta releases are for shoring things up; getting wide exposure and
finding out if our guesses and intuitions are correct. It's a time to
fix bugs and not to add new functionality. It's the time to focus on
responding to community feedback, and the time for pushing to a stable
GA release.  I hope to get Tapestry 3.1 to a beta stage very soon, as
soone as the Portal support goes in.

Anyway, those are my opinions, they are how I've attempted to run
Tapestry from its inception. Real like is always just an approximation
of such goals, but I want to re-empahsisze the unit tests and
documentation issues, which just become more important as more
developers are working within the same source.

-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org