Suggestions requested for Unit Testing process and build processes.

Question

Hi All,
We are using WebLogic WorkShop 8.1 SP2 to build our WebApp. One thing I am trying
to get together is a "Best Practises" list for aspects of WorkShop developement,
particularly Unit Testing, Continous Build methodology, source control management
etc.I have been through the "Best Practises Guide" that comes in WorkShop help,
but it doesnt address these issues.This could help us all for future projects.
1)Could anyone give pointers on how to perform Unit Testing using either JUnit/JUnitEE
in the WorkShop realm, given that Controls cannot be accessed directly from PO
Test classes.
2)For a project of size say 5 developers ,does it make sense to have a nightly
build using tools like CruiseControl?We use CVS for our source control and its
working out pretty well, but given that we currently have no Unit Tests that can
be run after the build and that can provide some reports on what broke/what didnt?
I am sure we all would appreciate any suggestions and more questions on this topic.
Thanks,
Vik.

Answer 1

Hi, Chris,
can you perhaps explain your solution in greater detail. I am really curious to
find a way to test controls.
"Chris Pyrke" <[email protected]> wrote:
>
I have written (well it's a bit of a dirty hack really) something that
lends itself
to the name ControlTest (it unit tests controls). Its a blend of Junit
and Cactus
with some of the source of each brutalised a bit to get things to work
(not much
- it was a couple of hours work, when I was supposed to be doing something
else).
To write a control test you code something like...
package com.liffe;
import com.liffe.controlunit.ControlTestCase;
import controls.Example;
public class TestExample extends ControlTestCase
private Example example = null;
public void setUp() {
example = (Example)getControl("example");
public void testExample() {
this.assertNotNull(example);
String result = example.getData();
assertEquals(result, "Happy as Larry");
Other tasks required to set up a test are creating a web project with
a jpf which
needs some cut and paste code (14 lines) in its begin method and a jsp
which is
also cut and paste (5 lines). (ie create a standard web project and paste
in 2
pieces of code)
In the web project you need to create a control (A) with an instance
name of controlContainer.
(if it's called something else the pasted in code will need changing
to reflect)
In this control you need to put an instance of TestContainerImpl and
any controls
that need testing.
You then need to add a method to the control (A) that looks like…
* @common:operation
public String controlTestRun(String theSuiteClassName, boolean xsl)
container.setControl("example", example);
return container.controlTestRun(theSuiteClassName, xsl);
You need to call container.setControl for each control being tested and
the object
'container' is the instance name of the TestContainerImpl that was put
in.
There are 4 jars (junit, cactus etc) that go in the library. You will
also need
the ControlUnitBase project (or maybe just it's jar).
To use you call a URL like:
http://localhost:7001/TestWeb/Controller.jpf?test=com.liffe.TestExample
TestWeb is the name I gave to my web project - this will be different
for each
test project
com.liffe.Example is the class above and will therefore be different
for each
test case.
You can also call
http://localhost:7001/TestWeb/Controller.jpf?test=com.liffe.TestExample&xsl=true
(Note the extra &xsl=true) and the browser will (if it can) render it
more prettily.
This seems to do the job quite nicely, but there are several caveats
I would hope
someone from bea would be able to address before I start using it widely.
1) To access the control you need to create it (eg as a subcontrol in
the control
(A) above.
To get it into the test case you need to pass it round as an Object (can't
return
Control from a control operation). As it's being passed around among
Java (POJO)
classes I'm assuming that control remains in the control container context
so
this is OK. It seems to work and the Object is some form of proxy as
any control
seems to be reproxied before the control is invoked from the test case.
2) If I'm testing controls called from a JPD then they either need to
be in a
control project (and my test cases called from a Web Project) which makes
for
a large increase in project numbers (we already have this and are trying
to resist
it) To avoid this - as a process project is a brain damaged web project
I simply
perform some brain surgery and augment the process project with some
standard
files found in any old web project. this means I can call the test JPF
from a
browser. This seems nasty, is there a better way?
3) I would like to be able to deliver without the test code. At the worst
the
code can be in place but must be inacessible in a production environment.
I don't
know how best to do this - any suggestions (without creating lots of
projects,
or lots of manual effort)
If anyone has read this far I would ask the question does this seem like
the kind
of thing that would be useful?
Hopefully a future version of workshop will have something to enable
unit testing
and this hacking will be unnecessary.
Could someone from BEA tell me if this is a dangerous way to do things?
Chris
"vik" <[email protected]> wrote:
Hi All,
We are using WebLogic WorkShop 8.1 SP2 to build our WebApp. One thing
I am trying
to get together is a "Best Practises" list for aspects of WorkShop developement,
particularly Unit Testing, Continous Build methodology, source control
management
etc.I have been through the "Best Practises Guide" that comes in WorkShop
help,
but it doesnt address these issues.This could help us all for future
projects.
1)Could anyone give pointers on how to perform Unit Testing using either
JUnit/JUnitEE
in the WorkShop realm, given that Controls cannot be accessed directly
from PO
Test classes.
2)For a project of size say 5 developers ,does it make sense to have
a nightly
build using tools like CruiseControl?We use CVS for our source control
and its
working out pretty well, but given that we currently have no Unit Tests
that can
be run after the build and that can provide some reports on what broke/what
didnt?
I am sure we all would appreciate any suggestions and more questions
on this topic.
Thanks,
Vik.