Thanks - I think you've just written a wiki document! This was more than I was expecting... Some thoughts/questions inlined.
Zachary Smith wrote:
As a control writer what sort of things do I have to worry about when moving between containers - other than accessing container specific resources such as Servlet stuff?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.
This one is probably over my head, but here it is anyway: Why not write a base test case, say BeehiveTestCase, which introspects for the @Inactive or @Freq annotations then use just the normal JUnit utilities/reports? It seems like there is a lot of duplication going on. I suppose if you want to run the same tests in multiple containers that might make sense though...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.
Thanks, I may take you up on that offer. My plan right now is to write a hibernate control then a class which uses that control. Then I'll exercise both those classes in the test case. I don't really plan on using TCH or driver method depending on the answer to my above question about drivers.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!
Regards,
- Dan
-- Dan Diephouse Envoi Solutions LLC http://envoisolutions.com/people/dan
