On Feb 23, 2010, at 3:14 AM, David Blevins wrote: > Hey Quintin! > > Checked this little gem in -- sorry it's taken so long to get it reviewed. > There's some good stuff in here. I was going to check it into a branch, but > it's in pretty awesome shape. Really gets the creative juices flowing. > > We can support @RunTestAs using the same code the container uses to support > @RunAs -- we could even use the same annotation. No need for a special > LoginModule We could also add in support for @TransactionAttribute and even > @Interceptors. All of the above will be a little sneaky and take a bit of > dancing, but totally doable. > > First thing though is I think we should flatten out all the abstractions that > aren't critical. The security stuff for example strings from OpenEjbRunner > to JUnit4Runner and through OpenEjbTestContext. With this approach it's > going to be real difficult to add more test method annotations. Most this > comes from trying to get away from direct JUnit 4 usage. I think for this > first iteration we can just make our lives simple, yank those abstractions > and just code straight against JUnit4. We'll probably end up with a third of > the code. So OpenEjbRunner and JUnit4Runner can get merged, TestContext can > get yanked and everything can become a Statement. > > What do you think?
Digging up this thread again. Did some more tinkering with this kind of concept. Check out: http://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/openejb-core/src/test/java/org/apache/openejb/core/stateless/StatelessContainerTest.java A cross between the stuff Quintin was working on and the validation test stuff that Karan did. Takes the "build and return an app" concept from Karan's work and pulls it into the "test runner with injection" that Quintin prototyped. The stuff that I hacked on is also not really ready for primetime as it doesn't do any scanning for apps in the classpath -- only the ability to build apps programmatically. Ideally we'd have both ... either in different test runners or the same. Tricky part obviously is that once we put something in front of users, we can't ever change it's behavior in any incompatible way. All the stuff we have goes a bit too far into the experimental. Wondering if doing a very stripped down version is the best approach to getting something out there and then float some of the ideas out in snapshots to get some feedback. Thoughts? -David
