Move Interceptors and Tests back into AS5 Workspace

[anil.saldhana]

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135044

Rather than hijacking ALR's thread, this thread contains my suggestions.

a) the ejb3 interceptors need to be back in AS/trunk/ejb3 module.
b) the ejb3 tests that require AS should ideally be in AS/trunk/testsuite or AS/trunk/ejb3

[alrubinger]

Thanks for moving this topic, Anil. Just don't continue to oblige me when I get cranky; you'll set a precedent. ;)

a) the ejb3 interceptors need to be back in AS/trunk/ejb3 module.

I'll leave this one for the other guys.

b) the ejb3 tests that require AS should ideally be in AS/trunk/testsuite or AS/trunk/ejb3

As it stands, we've got very little in the way of true Unit Tests. What we *do* have is a comprehensive series of integration tests written in JUnit, and at the moment, these are dependent upon AS for its execution environment.

So the direction in which I'd like to head is double-pronged:

1) Make a habit of extracting out business logic into easily-testable units, build up a Unit Test Suite.

For instance:

public performInvocation(){

 // Some code ...

 String someInvocationMetadata = Invocation.A_THREADLOCAL.get();
 // Do some stuff to "someInvocationMetadata"

 // Proceed ...

}

The above isn't easily testable; it depends on doing some logic to a variable obtained from an invocation/environment context.

In contrast, if we start to extract this out into an injectable manner, we can test it:

public performInvocation(){

 // Some code ...

 String someInvocationMetadata = Invocation.A_THREADLOCAL.get();
 this.adjustInvocationMetadata(someInvocationMetadata);

 // Proceed ...

}

public adjustInvocationMetadata(String someInvocationMetadata){

 // Logic

}

...and now we can mock up the invocation metadata in a Unit Test.

What this gets us in the end is a series of tests that will execute blazingly fast; we can easily push-button the Unit Tests in the IDE or from the CL and get back results without waiting for a full integration test run locally or in continuous integration.

2. Unbind Integration Tests from AS Where Possible

As we push forward with EJB3 Embedded, we'll be able to remove the dependency on AS for the majority of the integration tests, and leave only a few "AS-Specific Integration" Integration Tests.

So looking forward, it'd be great to do most of our functional- and specifications-related EJB3 Integration Tests in JUnit running EJB3 Embedded, with only a few tests for both EJB3 Standalone and EJB3 Deployers/AS to run through those areas. It's *here* that I think Anil's suggestion to put the tests within the EJB3 Module of AS is applicable, but only for the AS-specific ones.

Yet another reason to push through the Embedded Project; I'm really excited about that one and I think it's something the community will find beneficial - people love bootstrapping stuff into their Tomcat runtime.

In the meantime, a deprioritized project at which I've been chipping away is a Mavenized version of our TestSuite; at the moment we're still delegating this portion off to the legacy Ant scripts.

Would love to see more open discussion about the future of our testing practices here.

S,
ALR

[anil.saldhana]

What you need when you get cranky is a nice spanking. ;)

Regarding junit based tests in the ejb3 project, they mainly test minute functionality (avoid NPEs also), define input/output from the functionality etc. Testing functionality in small bits can reveal issues that integration tests will not or take a long long time in resolving.

The issue is the effort in isolating the functionality in bits that need to be unit tested. You have got to start sometime in getting there. :)

[alrubinger]

What you need when you get cranky is a nice spanking. ;)

Please move this to "Design of Inappropriate Advances in the Workplace".

The issue is the effort in isolating the functionality in bits that need to be unit tested. You have got to start sometime in getting there. :)

So I think we're of the same views there. You bring up some great points, I think we just need to figure our migration path to this type of setup, and slowly introduce this externalization into our workflow.

S,
ALR

[wolfc]

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135044

Rather than hijacking ALR's thread, this thread contains my suggestions.

a) the ejb3 interceptors need to be back in AS/trunk/ejb3 module.
b) the ejb3 tests that require AS should ideally be in AS/trunk/testsuite or AS/trunk/ejb3

Why?

You have already answered the 'why not (move back)?' yourself.

[anil.saldhana]

AS integration stuff (including the ejb3 tests that require AS) should really be in the AS workspace. I am not referring to ejb3 unit tests that test ejb3 functionality (They can stay where the ejb3 core is)