Scott,
Hmmmmm. I think my productivity was increased by using Spring. I
understand their point, but
when layering components it seems that using Spring to assemble the test
as it would be in a
final configuration seems like the way to go. I agree that starting up
the whole J2EE container
would be overkill and bad from a testing POV, but using it to setup one
or two associated
components seems valid.
Anyway, are you planning on converting the existing tests, (i.e.
portal-site or profiler)?
Randy
Scott T Weaver wrote:
Randy,
Here is some info on the logic behind this. However, it is no problem to
revert back to the Spring configured test cases.
http://www.springframework.org/docs/reference/testing.html#unit-testing
-----Original Message-----
From: Randy Watler [mailto:[EMAIL PROTECTED]
Sent: Friday, July 15, 2005 4:37 PM
To: Jetspeed Developers List
Subject: Re: [jira] Created: (JS2-309) Improve and streamline testcase
development in Jetspeed
Scott,
Why do people recommend not using Spring to setup testcases? This seems
odd to me... i just used Spring to setup the portal-site testcase
precisely because I did not want to setup all of the PageManager stuff
in my testcase code. Is this simply a performance thing or what?
Randy
Scott T Weaver (JIRA) wrote:
Improve and streamline testcase development in Jetspeed
-------------------------------------------------------
Key: JS2-309
URL: http://issues.apache.org/jira/browse/JS2-309
Project: Jetspeed 2
Type: Improvement
Components: Testing
Versions: 2.0-M4
Reporter: Scott T Weaver
Assigned to: Scott T Weaver
Fix For: 2.0-M4, 2.0-FINAL
I want to make it easier on us to write high-performance test cases
against Jetspeed components. Currently we rely on sections of and in some
cases the entire Jetspeed Spring engine to initialize and run our tests.
I have read articles advising * NOT * to use this approach inside your
test cases and that you should hand-assemble the components within the
test cases themselves. We also have some clunky test case inheritance
hierarchies (I will take the blame for that) that initialize more than we
need in most cases. What I am doing to solve this is to, instead of using
abstract test cases, put together small set "TestHelper" components that
have there own setUp(0 and tearDown() methods that perform specific
functions such as initialize a datasource pool and properly initializing
OJB, etc. The datasource and OJB helpers are already in place and I have
them working in the registry tests with very little change to the test
cases themselves.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
