Hi Luciano,
Sorry to get on my soapbox but...I would break this down into two
separate areas, testing and debugging of an extension versus an
application:
1. Testing and debugging of an extension
I would separate testing into three categories: unit testing,
integration testing, and acceptance testing.
Unit testing the container should focus on verifying very fine-
grained things, typically one class. Sometimes a class may depend on
another in which case we have been using EasyMock as a way to stub it
out. If it doesn't make sense to stub things out, then unit testing
may involve more than one class but if there are a lot of classes
that are required generally it is a sign that the design needs to be
refactored... In unit tests, the SCA container is not needed and
accessing external things like SCDL or writing to the file system
should be avoided. Just extend TestCase. In core we were even able to
do this for the STaXElementLoader implementations by using EasyMock
to mock out XMLStreamReader (e.g.
ComponentTypeElementLoaderTestCase). Taking this approach offers a
number of benefits. It helps with design since if a class cannot be
tested on a fine grained level, something is generally wrong with the
design (http://no-new-ideas.blogspot.com/2006/11/is-clutter-in-your-
test-trying-to-tell.html). If a test fails, it is apparent what broke
since the test is very specific, generally verifying one thing. Unit
tests document the operation of particular classes, making it easier
for people coming into the project to understand the architecture.
Not accessing external artifacts avoids side effects (and failed
tests due to things like classpath peculiarities) and makes things
run fast. Also, all of this makes it easy to run the entire unit test
battery very frequently and hence speeds up the dev cycle. I
typically make changes on core and then run the ~500 unit tests in
about 10 seconds. Hopefully we will wind up with a lot more tests but
if we can keep the time it takes to run them down, developing Tuscany
will be easier. Unit tests are always run prior to checkin. Debugging
individual classes is also dead simple in this case as there is just
a JUnit TestCase to run.
Integration testing for me breaks down into a couple of types. Tests
that are a little larger than unit tests which are design to verify
the interaction of parts of an extension.There are also integration
tests that deal with particular code paths through an extension but
not an application scenario (the paths are more specific and may
involve negative testing). For example, ensuring that an extension
can properly boot from the extension SCDL. For this, there is
SCATestCase. There are a third type of integration tests which deal
with larger issues such as verifying an extension works with other
extensions are in a particular host environment (e.g. standalone,
Tomcat, etc.). Some integration tests (the first type) would be run
as part of the checkin build. Types 2-3 would be run as part of
Maven's integration test phase on an integration server (in case you
haven't come across it, Fowler has a good overview: http://
www.martinfowler.com/articles/continuousIntegration.html). Debugging
in this case could be done either remotely or by running SCATestCase
in an IDE.
Acceptance testing verifies applications function correctly from an
end-user perspective. This would involve testing the samples. I would
expect these tests would only be run infrequently to verify if a
particular build was stable.
2. Application testing/debuging
I think there is a separate issue around allowing end users to test
and debug their applications. Typically, for testing they should not
need SCA until they perform integration tests. Here I think DAS is
not much different than an application that runs with JPA or
Hibernate (sorry to keep drawing the same analogy). In most cases, I
stub out the service that persists things (i.e. the DAS component or
the service that uses JPA/Hibernate) with EasyMock or something
else. However, I probably also want to test that my DAS service
works correctly. In this case, I think it would be helpful to build a
simple test harness for users to be able to bootstrap the DAS
component and fire of tests. This may include loading a DataSource
(DBCP works well for this stuff) and an embedded database (I think
you guys are using Derby, I really like HSQLDB since it is small and
has an in-memory mode). You could even create something like
SCATestCase that either takes a SCDL on the file system or some type
of InputStream. This would make debugging really easy. It also makes
testing for very specific things like transaction rollbacks and
deadlock detection much easier.
Sorry for such a long winded reply - I'm happy to help out with
anything that I can.
Jim
On Nov 13, 2006, at 10:27 AM, Luciano Resende wrote:
I'm working with Amita's contribution (
http://issues.apache.org/jira/browse/TUSCANY-904) to modify the DAS
container implementation in order to get it ready to go to the
trunk and
would like to see what's the best approach for performing unit
testing and
debuging a SCA Container.
Any help would be appreciated
Thanks
Luciano Resende
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
