According to http://incubator.apache.org/beehive/controls/controlsProgramming.html, there are four possible ways for user to instantiate controls:
1. declarative instantiation without property reset(@Control); 2. declarative instantiation with property reset(@Control with @Property); 3. programmatic instantiation without property reset; 4. programmatic instantiation with property reset; Is ControlTestCase going to cover them all? Furthermore, controls could also raise events, which could be captured by @EventHandler. How could this be addressed? -James -----Original Message----- From: Eddie ONeil [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 21, 2005 1:31 PM To: Beehive Developers Subject: junit test container All-- I've written a small, standalone JUnit test container that can be used for out-of-container testing of Controls. This is a pretty simple set of classes that are described below. When a test class runs, a new control container context is created and control fields declared with @Control are instantiated, the test code executes, and both the context and controls are removed. I think this should be sufficient to replace the custom control test containers defined in both the JDBC and web service controls. Non-goals of this test container include: - facilitate in-container testing as part of EJBs / Servlets / JSPs / ServletFilters / etc. Frameworks like Cactus are good at this sort of thing, and Beehive should ensure that the facilities to ensure controls in a test case work there. - define a new annotation-based model for writing test classes / test methods. JUnit 4.0 and TestNG are already defining these annotations / semantics. The classes involved are: - ControlTestCase -- abstract base class used to setup the control container context and initialize fields marked with @Control. Also has convenience methods for creating controls programmatically. - ControlTestUtils -- static helper methods that can be used in a test environment when a test case needs to extend a different base class. These would be called in user code from the setUp / tearDown methods. - ControlTestContainerContext -- simple ControlContainerContext implementation that allows a test author to wire-up contextual services, etc and a sample test is pasted at the bottom of the mail: I'm considering putting this in the tree under: trunk/controls/src/junit-testing/... and producing a JAR called "beehive-controls-junit-testing.jar" that can be used from the samples / applications / etc and is included in the Beehive distribution. It's definitely time that we started making this sort of testing easier. :) Thoughts / comments? Eddie ::::: sample test public class ContainmentTest extends ControlTestCase { @Control private Hello _declarativeHello; public void testDeclarativeInstantiation() { System.out.println(_declarativeHello.hello()); } public void testContainment() { Hello hello = (Hello)instantiateControl("pkg.containment.HelloBean"); System.out.println(hello.hello()); } }
