Moving some of the testing discussion out of the samples thread... Its not completely clear to me what the distinction is between 'technology samples' and functional tests. There are some JavaScript samples in the samples directory: http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/JavaScript/, which of these should be samples and which should be tests, and where should they fit in the Tuscany directory structure? I'm quite happy to move some or all of these or change them to be testcases, tell me what you'd like.
Could there be some specific examples of how we should be doing functional and integration testing of things like the WS binding entryPoints and externalServices? It was done by running the WS samples in testing/tomcat, whats a better approach? I really don't understand why samples shouldn't be tested as part of the regular build. What is the old ground being rehashed, the best I can find is the comment at the very end of this email which no one posted any disagreements to: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/[EMAIL PROTECTED] I'd be careful with -1'ing commits where you don't like the test coverage. It would be far better to offer guidance and specific constructive criticism, or even help add tests if you think some code is lacking. We need to foster an environment where people want to join in and help, throwing around vetos isn't going to do that, and if using vetos becomes common practice they will likely be used back at you when you least expect or want them. Everyone acknowledges the current code needs improved testing, so if nothing else -1s would be a bit hypocritical. Vetos are always available as an option of last resort, but I think they're best kept for that - a last resort - after attempts to resolve a problem have failed. ...ant On 4/14/06, Jeremy Boynes <[EMAIL PROTECTED]> 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? > > -- > Jeremy >
