For testing purposes we've been using Junit for functional testing for
model and controller layer;
View layer and as such the whole lifecycle was regression tested with
for example grinder.
As anio mentioned you need to get in to the framework to get more
aquanted with it and to learn how the lifecycle, binding layer, etc.
for this reasons it's very important to list all needed tasks for
every developer very granularly so each developer learns to dive into
the code and learn more about the engine underneath.
In each developer track, and for each role (orm, controller, view-
layer) the developers are obliged to define all needed testing scripts
such as junit so regression testing can be performed troughout each
fase of the project.
We've even had a project defined were the developer had to buy the
team a beer each time a test failed, that was a very pleasant way of
having a very good timespirit and a strong focus. Sometimes the team
got pretty drunk ;o))
But still some more detailed best practices on testing could be
mainingfull because now the architects have to decide which testing
approach to use. When looking into the latest bpel release we now have
a full blown test suite to use to automate testing for bpel processes.
If the same testing framework could be used for ADF as well, you could
test the integration aspects as well and have the full lifecycle
dependencies tested with one single approach.
On Sep 6, 7:40 am, Chris Muir <chriscm...@gmail.com
> As follow up, there's an interesting post at the following link about
> unit testing, why it's a difficult exercise for enterprise scale
> systems and organisations, and why it's important in the context of
> other system build concepts such as continuation intregration and
> predictable builds: