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