On Apr 13, 2006, at 7:18 PM, Jeremy Boynes wrote:
ant elder wrote:
Here are some specific ideas to kick around:
1) how about calling business samples 'demos' and technology
samples just
'samples'
I tend to agree with Simon that there could be a perception that
"demos"
are just mockups with no substance. I do think thought that there is a
difference though between business and technology samples.
In J2EE days the business samples were called "blueprints" so
perhaps we
could call them that as well - would be a natural place for a
petstore :-)
2) restructure the current samples folder to be something like:
samples
- demos
- bigbank
- petstore
- ...
- das
- ...
- sdo
- ...
- sca
- bindings
- jsonrpc
- ws
- ...
- componentTypes
- java
- javascript
- ...
I'm a little concerned about the depth of the tree here but the idea
looks good.
3) There should be a consistent set of samples within bindings,
componentTypes etc so its easy to copy things to create new
samples and add
new function
+1
4) samples are like functional tests so we should add a sample for
every bit
of existing and new function
-1
Business samples illustrate business application and should focus on
that. Technology samples illustrate how to use the technology and
should
focus on that.
Functional tests test function and should focus on that. If possible
they should run as part of the build using the maven test framework.
5) Fix the testing/tomcat stuff so all the samples doing
functional testing
get run as part of a regular build
-1
Fix the functional/integration tests so that they are an integrated
part
of the build rather than a bolt-on using different infrastructure. As
Jim said we have been here before.
I will point out that there are huge areas of the code where we do not
even have unit test coverage even though that is trivial to add to the
build. We need to stop building samples for testing and put some
effort
into real testing and samples that clearly illustrate key technology
and/or business application.
I'll plead guilty here as there are very few unit tests for the loader
framework. So right now I'm committing to go back and add tests there.
How about if everyone volunteers to go write unit and/or integration
tests for some part of the code they worked on?
Let's go further - given we're all supposed to be reviewing
commits, how
about we start to -1 changes that don't have tests associated with
them?
I think this would actually be a good policy as long as we say it
applies for most changes (e.g.. performance changes maybe not but
definitely for bug fixes) .
Thoughts?
--
Jeremy
