----- Original Message ----- From: "Russell Butek" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 15, 2002 7:54 AM Subject: Architecture proposals for face-to-face
> Folks, here's a document that we (IBM) were planning to present at the > face-to-face next week. Since we're not going to make it, I'll present it > here. The intent of this thing is to get us all on the same page with > respect to how we proceed with AXIS development. It is intended to be a > living document that everyone can add to and debate (with this in mind, I > suggest we store it in CVS). As items on this document are resolved, we > can implement them and describe them in the architecture guide. > Proposal 10: Re-write Test Harness Status: Proposed Proposed By: Rich Scheuerle and others Description Here are some objectives: a.. Ability to run a single test. b.. Ability to run a bucket of tests c.. Ability to run all the tests d.. Ability to run the tests that do not rely on remote resources. e.. Ability to run tests if connection problems occur with remote resources (with warnings). f.. Simpler installation of tests. Best would be auto installation without changes to the build.xml files. Give non-committers the ability to quickly give us a test that we can drop in; thus giving the group a good set of user provided tests. g.. Fully documented process. Justification The current test harness is becoming too complicated. ------------ +1 The current approach isnt scaling; and if one fails then everything breaks. And it takes a long time to run, hence the timeouts. Possible solutions 1. refactor the build files to all load shared property, taskdef, classpath declarations through XML entities (easy; can be done on a case-by-case basis; works w/ all versions of ant) 2. Write a new ant task that does bulk <ant> on files in subdirs; has a failonerror property to keep going if there are failures. This is the fabled <anton> task that has historically been rejected on ant-dev because " a master build should know about its child builds". With one test per (refactored) build file, drop in execution would be nice 3. extend Junit, write a test case descendent that generates tests against build files. The intent would be to get a nice junit formatted http status report 4. something fancy with XSLT -take one or more test descriptor files -generate ant build files dynamically from these -run 'em -have the output coalesced into a fancy junit http status report 5. Run some tests in parallel. Each test should be independent, so we can run them side by side and get through the test suite faster, especially on a multi-cpu box. This may throw up concurrency bugs, which is a good thing. I think the combinaiton of options (1, 4, and 5), with some hosting mechanism (like 2 or 3) would work There is a lot that could be done to clean up
