Dan, Getting some docs on the Controls test framework is on my plate at the moment. I'll be writing up something (probably to the wiki) soon but here is the nickel tour.
*** A controls normally consists of four pieces *** 1. The control you are using for the test. Often a simple Hello World control 2. A driver file which contains the code which exercises the test control and reports a status (more about this in a second) 3. Client code: this is usually a JPF and or JWS (and in some cases a POJO) 4. A JUnit file which drives the test Q. What is Milton? A. Milton is a test writing methodology with some utility classes to support it. The basic behind Milton is that Controls test take place inside of a container which is accessed "remotely" in most cases. For Beehive that is generally HTTP to a PageFlow or WSM WebService. Milton makes the assumption that the test code - that is the code which is exercising a control and determining pass/fail/abort - resides within the client (jpf/jws). Milton provides utilizes to simplify the writing of supporting test code and lets the test writer focus on writing the test at hand and hopefully worry less about container specifics. Currently there is Milton utility code for running tests in JPF; WSM JWS will follow soon. Q. What is a Driver? A. As I alluded to above, a Driver is a Java class which contains the methods which exercise a test control. An instance of the Control you wish to exercise in declared or instantiated in the client code (jws/jpf) and an instance of it is passed into a driver either via a setter, constructor, or directly into the test method on the driver. The methods inside the driver are then invoked by the client and the driver returns the result. Quite simply, a driver is the holder of the test code. The reason for this is so that a control test can be moved from one client context or container to another with very little effort and without copy & paste. For example, I may setup a test which uses JPF and then want to also run that test in the context of a JWS or even a POJO or some new container I whip up. Using a driver makes porting that test incredibly easy. JUnit --> JPF/JWS/Java + @Control --> Driver(Control inst) --> Report Q. What is TCH? A. (T)est (C)ontrol (H)arness is a test management, running, and reporting system. It sits right on top of JUnit and adds a level of fine grained management over what tests are run and how they are reported. An example of its use would be the fact that we intend to have a rather large body of tests but we wish to designate some as "checkin" (or drt) and "detailed" (or bvt) and select which ones we wish to run. Another would be to disable a test - we may have a JUnit test which we know is breaking and wish to disable it until a fix is in. This can be done with setting the 'status' on a test to "inactive". TCH is an extension to ant and runs with ant style build.xml files. These xml files can be maintained by hand but we have developed another utility which annotates the JUnit files which we process and generate the xml files that are fed to TCH. That tool is called Mantis. Q. What is Mantis? A. Mantis is an APT annotation processor which looks at annotations on a Controls JUnit file and generates test.xml which is fed to TCH for running and reporting. I would like to point out that behind it all Controls tests are run as JUnit files and so they can be run via a basic JUnit runner. The tools which we have overlaid are to simplify management of the large body of tests we expect and utilities to support test methodology (ie, Milton). I will work on getting some real docs written with some howto's and examples and let the list know when that's available. I'd love to help you and anybody else start writing tests so if you have specific implementation questions and ideas please let me know! #!/zach -----Original Message----- From: Dan Diephouse [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 9:39 PM To: Beehive Developers Subject: Re: Blank controls app template checked in Ken Tam wrote: >Dan, if you want to see mock container style tests, look at the code >under controls\test\src\drivers. Each driver essentially sets up its >own container. Zach & James did most of the initial work here and can >explain how the current approach works.. We probably need to publish >some docs/roadmaps on the test infrastructure, I'll file a JIRA issue. > > > Could someone give a quick overview of whats happening with the tests and the drivers directory? Also, I see mantis, milton, tch which are supporting tools. How do these fit in? - Dan -- Dan Diephouse Envoi Solutions LLC http://envoisolutions.com/people/dan
