James, yes, there are certainly those four ways of instantiating
controls. The test container supports both of the declarative
instantiation cases (@Control). As far as the other manual
instantiation cases, I'm still a little on the fence about including
"helper" methods for declarative instantiation as
Controls.instantiate(...) is a perfectly usable API. But, if folks
think they're useful, we can certainly add some -- reasonable :) -- set
of convenience methods. I'd just rather let test authors use the usual
Control APIs as often as possible.
Patrick, I'm not sure it's the job of the test container to help bind
objects into JNDI. It's certainly a utility that could be added, but
the main job of the container is to support instantiation of control
instances. In the case you pasted below, assuming that your test case
had bound a DataSource to "java:comp/env/jdbc/perf" or the test was
running in-container, yes, the "jdbcControl" would be initialized
correctly.
Hope that helps clarify things. :)
Eddie
Patrick Osborne wrote:
Eddie,
Is there support for JDBC controls that use a data source? For example
if you the following annotation when declaring a control will it work?
@Control
@JdbcControl.ConnectionDataSource(jndiName =
"java:comp/env/jdbc/perf")
private MyJdbcControl jdbcControl;
Thanks,
Patrick.
Eddie ONeil wrote:
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());
}
}
