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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
