You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Chad Schoettger <ch...@gmail.com> on 2006/07/06 18:58:51 UTC
Porting the controls drts from tch to junit
I've ported most of the core control's drt's from the tch test
framework to Junit tests (using the ControlTestContainer). The only
ones that haven't been ported are those tests which use a page flow as
the control container.
Does anyone have thoughts on what should be done with the tch jpf tests?
I can think of a couple of options:
1 - Go ahead and remove them from the tree, they all have equivalent
JUnit tests with the only difference being the control container. If
removed we would no longer have a dependency on the tch test
framework.
2 - Don't remove them and keep the tch dependency.
- Chad
Re: Re: Porting the controls drts from tch to junit
Posted by Chad Schoettger <ch...@gmail.com>.
Thanks for the input, I'll start taking a look at moving the jpf
controls tests into the netui test framework.
- Chad
On 7/7/06, Eddie O'Neil <ek...@gmail.com> wrote:
> Totally -- to reiterate my stance on this from the other thread, I'd
> prefer to have tests for integrating Controls into NetUI in the NetUI
> test suite. To be clear, there aren't JPF dependencies on core
> Controls today -- just on the tests.
>
> I can totally understand arguments to the contrary -- namely making
> sure commits to Controls don't break other components, but with a
> sufficient enougn Controls test suite, this shouldn't be a problem for
> controls/ commits. With this, it falls into the NetUI camp to keep
> the web-tier end of the integration working.
>
> So, I'm +1 for moving the tests to NetUI (but am not in favor of
> deleting them outright).
>
> Eddie
>
>
>
> On 7/7/06, Kenneth Tam <ke...@gmail.com> wrote:
> > +0 on removing JPF dependencies from controls.
> >
> > In general my position is that users are better served by looser
> > coupling between the functional components in Beehive; it makes
> > initial adoption and ongoing experimentation easier.
> >
> > On 7/6/06, Chad Schoettger <ch...@gmail.com> wrote:
> > > I've ported most of the core control's drt's from the tch test
> > > framework to Junit tests (using the ControlTestContainer). The only
> > > ones that haven't been ported are those tests which use a page flow as
> > > the control container.
> > >
> > > Does anyone have thoughts on what should be done with the tch jpf tests?
> > >
> > > I can think of a couple of options:
> > >
> > > 1 - Go ahead and remove them from the tree, they all have equivalent
> > > JUnit tests with the only difference being the control container. If
> > > removed we would no longer have a dependency on the tch test
> > > framework.
> > >
> > > 2 - Don't remove them and keep the tch dependency.
> > >
> > > - Chad
> > >
> >
>
RE: Porting the controls drts from tch to junit
Posted by Steven Tocco <st...@bea.com>.
Eddie/Chad,
I am in agreement on NetUI owning those tests.
Seems to me the biggest area of concern in running those types of
integrated tests would be control lifecycle management while being used
in the context of a page flow. (state init, state destroy,
failover/serialization) Without these tests I think we would always be
wondering if the stand-alone control container was representative.
The reason I mention this is that the scope and number of those tests
might be reduced to primarily focus on the container management piece.
While I don't think that makes the selection of how those tests are run
any easier, it might limit their scope going forward and be a clearer
roadmap for committers why there may be redundancy and where to add unit
tests.
Hope that made sense,
Steve
-----Original Message-----
From: Eddie O'Neil [mailto:ekoneil@gmail.com]
Sent: Friday, July 07, 2006 6:15 PM
To: Beehive Developers
Subject: Re: Porting the controls drts from tch to junit
Totally -- to reiterate my stance on this from the other thread, I'd
prefer to have tests for integrating Controls into NetUI in the NetUI
test suite. To be clear, there aren't JPF dependencies on core
Controls today -- just on the tests.
I can totally understand arguments to the contrary -- namely making
sure commits to Controls don't break other components, but with a
sufficient enougn Controls test suite, this shouldn't be a problem for
controls/ commits. With this, it falls into the NetUI camp to keep
the web-tier end of the integration working.
So, I'm +1 for moving the tests to NetUI (but am not in favor of
deleting them outright).
Eddie
On 7/7/06, Kenneth Tam <ke...@gmail.com> wrote:
> +0 on removing JPF dependencies from controls.
>
> In general my position is that users are better served by looser
> coupling between the functional components in Beehive; it makes
> initial adoption and ongoing experimentation easier.
>
> On 7/6/06, Chad Schoettger <ch...@gmail.com> wrote:
> > I've ported most of the core control's drt's from the tch test
> > framework to Junit tests (using the ControlTestContainer). The only
> > ones that haven't been ported are those tests which use a page flow
as
> > the control container.
> >
> > Does anyone have thoughts on what should be done with the tch jpf
tests?
> >
> > I can think of a couple of options:
> >
> > 1 - Go ahead and remove them from the tree, they all have equivalent
> > JUnit tests with the only difference being the control container.
If
> > removed we would no longer have a dependency on the tch test
> > framework.
> >
> > 2 - Don't remove them and keep the tch dependency.
> >
> > - Chad
> >
>
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
Re: Porting the controls drts from tch to junit
Posted by Eddie O'Neil <ek...@gmail.com>.
Totally -- to reiterate my stance on this from the other thread, I'd
prefer to have tests for integrating Controls into NetUI in the NetUI
test suite. To be clear, there aren't JPF dependencies on core
Controls today -- just on the tests.
I can totally understand arguments to the contrary -- namely making
sure commits to Controls don't break other components, but with a
sufficient enougn Controls test suite, this shouldn't be a problem for
controls/ commits. With this, it falls into the NetUI camp to keep
the web-tier end of the integration working.
So, I'm +1 for moving the tests to NetUI (but am not in favor of
deleting them outright).
Eddie
On 7/7/06, Kenneth Tam <ke...@gmail.com> wrote:
> +0 on removing JPF dependencies from controls.
>
> In general my position is that users are better served by looser
> coupling between the functional components in Beehive; it makes
> initial adoption and ongoing experimentation easier.
>
> On 7/6/06, Chad Schoettger <ch...@gmail.com> wrote:
> > I've ported most of the core control's drt's from the tch test
> > framework to Junit tests (using the ControlTestContainer). The only
> > ones that haven't been ported are those tests which use a page flow as
> > the control container.
> >
> > Does anyone have thoughts on what should be done with the tch jpf tests?
> >
> > I can think of a couple of options:
> >
> > 1 - Go ahead and remove them from the tree, they all have equivalent
> > JUnit tests with the only difference being the control container. If
> > removed we would no longer have a dependency on the tch test
> > framework.
> >
> > 2 - Don't remove them and keep the tch dependency.
> >
> > - Chad
> >
>
Re: Porting the controls drts from tch to junit
Posted by Kenneth Tam <ke...@gmail.com>.
+0 on removing JPF dependencies from controls.
In general my position is that users are better served by looser
coupling between the functional components in Beehive; it makes
initial adoption and ongoing experimentation easier.
On 7/6/06, Chad Schoettger <ch...@gmail.com> wrote:
> I've ported most of the core control's drt's from the tch test
> framework to Junit tests (using the ControlTestContainer). The only
> ones that haven't been ported are those tests which use a page flow as
> the control container.
>
> Does anyone have thoughts on what should be done with the tch jpf tests?
>
> I can think of a couple of options:
>
> 1 - Go ahead and remove them from the tree, they all have equivalent
> JUnit tests with the only difference being the control container. If
> removed we would no longer have a dependency on the tch test
> framework.
>
> 2 - Don't remove them and keep the tch dependency.
>
> - Chad
>
Re: Porting the controls drts from tch to junit
Posted by Carlin Rogers <ca...@gmail.com>.
Chad,
I'm not too familiar with the page flow tests that are in controls. Some of
the existing tests in the coreWeb BVT may already have some of the same test
coverage. If not, then Eddie's suggestion to utilize the existing
TestRecorder framework for any tests you want to move into NetUI, sound good
to me.
I can point you to some of the existing tests...
some control interfaces and implementation files are in
netui/test/webapps/drt/src/org/apache/beehive/netui/test/controls/
and the page flows are in
netui/test/webapps/drt/src/controls/
There are also tests in
netui/test/webapps/drt/{src,web}/pageFlowCore/controlsContextualServices/
netui/test/webapps/drt/{src,web}/pageFlowCore/inheritControls/
netui/test/webapps/drt/{src,web}/pageFlowCore/lifecycle/
Carlin
On 7/6/06, Chad Schoettger <ch...@gmail.com> wrote:
>
> I've ported most of the core control's drt's from the tch test
> framework to Junit tests (using the ControlTestContainer). The only
> ones that haven't been ported are those tests which use a page flow as
> the control container.
>
> Does anyone have thoughts on what should be done with the tch jpf tests?
>
> I can think of a couple of options:
>
> 1 - Go ahead and remove them from the tree, they all have equivalent
> JUnit tests with the only difference being the control container. If
> removed we would no longer have a dependency on the tch test
> framework.
>
> 2 - Don't remove them and keep the tch dependency.
>
> - Chad
>