Hi All... On 3/8/07, David Blevins <[EMAIL PROTECTED]> wrote:
On Mar 8, 2007, at 11:05 AM, Prasad Kashyap wrote: > On 3/7/07, David Blevins <[EMAIL PROTECTED]> wrote: >> Just to add to what Mohammad mentions (which was all great advice). >> >> This one is a pretty hard set of tests to write considering the sheer >> volume of tests and beans/interceptors we'll have to write. > > Considering the sheer volume of tests, beans and interceptors we need, > shall I proceed by making a separate package for interceptors ? > Maybe. Generally we divide the tests up by component section (cmp1, cmp2, bmp, stateless, stateful, mdb), but from a certain perspective interceptors could be considered a new top-level component. What do others think?
I think it is better to continue with the current scheme, that is not considering interceptors as a separate component, and add them to the current available beans as needed. If we do that we'll still definitely want a bean in each of the
existing section (cmp1, cmp2, bmp, stateless, stateful, mdb) that has single bean that tests the InvocationContext methods. We could do that again in the potential interceptor section of the test suite. > Also, as we discussed on irc, we may even have to have a separate jar > for the default interceptor tests if we really want to use the "*" > wildcard entry. Else every business method in every bean will get > intercepted. It's probably unavoidable to have a separate jar for the package- level annotation stuff (aka. default interceptors). Otherwise they'll get executed on all our existing tests which wouldn't be good. I wonder if we can still put the majority of the interceptor tests in the main jar still. That part will probably have to be cook's choice :) -David >> >> Some basic things about interceptors we have to cover: >> >> Interceptors can be declared at three levels: package, class, >> method >> All declared interceptors (package, class, method) stack up to one >> big chain unless excluded via: @ExcludeDefaultInterceptors (on class >> or method to exclude package interceptors), @ExcludeClassInterceptors >> (on method to exclude class interceptors) >> Interceptors are executed in the order they are declared (stacked). >> Throwing an exception stops the chain of execution. >> Interceptors can intercept these lifecycele callbacks: >> @PostConstruct, @PreDestroy, @PrePassivate (stateful only), >> @PostActivate (stateful only) >> Interceptors and/or the *bean* itself can intercept any business >> method via: @AroundInvoke >> Each method on InvocationContext should be tested >> These types of beans can have interceptors: MDB, Stateless, >> Stateful >> >> As far as how to implement stuff, we generally try to group tests by >> function in increasing order. Meaning we'd want a test case to test >> the methods of InvocationContext before we start testing chains of >> interceptors because in the InvocationContext has to be functional >> before any chains could work. >> >> Hope this helps. It usually takes a lot of work up front just do get >> a clear attack plan. Usually once that is there writing the actual >> tests is easy (by comparison anyway). >> >> -David > > Thanx > Prasad >> >> >> On Mar 7, 2007, at 10:12 AM, Prasad Kashyap wrote: >> >> > Thanx Mohammad. Those were all good tips indeed. >> > >> > Cheers >> > Prasad. >> > >> > >> > On 3/7/07, Mohammad Nour El-Din <[EMAIL PROTECTED]> wrote: >> >> Hi Prasad... >> >> >> >> First of all, welcome of the OpenEJB family :). I know this mail >> >> is directed >> >> to David, but I want to give a suggestion regarding the second >> >> part of your >> >> question, and as I was involved in developing some iTests for >> >> OpenEJB. See >> >> my comments below please :) >> >> >> >> >> >> >> >> On 3/7/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: >> >> >> >> > On 3/2/07, David Blevins <[EMAIL PROTECTED]> wrote: >> >> > > Hi Prasad, >> >> > > >> >> > > Welcome to the fun! I really wouldn't be concerned about >> being a >> >> > > "hindrance". Help is help, and we're happy to have you! >> >> > > >> >> > > Couple things I think need some attention is that pretty soon >> >> here >> >> > > we're going to have to produce some of the interceptor tests >> >> we have >> >> > > planned out. There's a whole bunch of them in this list: >> >> > > http://issues.apache.org/jira/browse/OPENEJB-142 >> >> > >> >> > I'm ready to start writing tests for the interceptor for the >> above >> >> > JIRA. Had you envisaged these tests to be in any particular >> >> way ? Your >> >> > thoughts/advice/opinions will be well appreciated. >> >> > >> >> > Should I write separate beans for these or should I reuse the >> >> existing >> >> > beans ? >> >> >> >> >> >> Well I did not look at the interceptor code, but I tried to follow >> >> this rule >> >> while developing unit tests, if it is applicable to reuse a bean, >> >> and just >> >> add some new members to it so u can test the required feature, it >> >> will be >> >> better, if not or if it will complicate things start a new one and >> >> also try >> >> to reuse what ever possible by extending some other bean or so. >> >> take a look >> >> at the following beans BasicStatelessPojoBean, >> >> FieldInjectionStatelessBean, >> >> SetterInjectionStatelessBean and >> >> AnnotatedFieldInjectionStatelessBean, and >> >> remember it is always a good practice to review the specs before >> >> writing >> >> tests, this way you can know how OpenEJB really should behave, >> >> this is what >> >> I've been doing at least. And feel free to take the time you need, >> >> it took >> >> me a while to write my first test case, and I did it by the help >> >> of DBlevins >> >> too :D, there is no shame to get help as long as it will help >> you to >> >> contribute more for this project :). Welcome again Prasad :), and >> >> have fun >> >> :) >> >> >> >> Cheers >> >> > Prasad >> >> > >> >> > > >> >> > > The interceptor code is not yet functional, but writing the >> >> tests is >> >> > > actually harder in a lot of ways and whoever takes that on is >> >> likely >> >> > > going to have to dig through the spec quite a bit around the >> >> topic of >> >> > > interceptors. But for that reason it's a great place to learn >> >> and >> >> > > eventually crack into the other runtime code. Ask Mohammad >> >> or Manu :) >> >> >> >> >> >> Yeah, David is right writting tests for OpenEJB is really nice >> >> place to >> >> start and it is a challenging task too in some situations :) >> >> >> >> > >> >> > > Another budding area is we have some additional validation >> needs >> >> > > around some of the new EJB 3 concepts. We have a list started >> >> here: >> >> > > http://issues.apache.org/jira/browse/OPENEJB-453 >> >> > > >> >> > > Anyone else have any ideas? >> >> > > >> >> > > -David >> >> > > >> >> > > >> >> > > On Mar 2, 2007, at 11:55 AM, Prasad Kashyap wrote: >> >> > > >> >> > > > Hello all, >> >> > > > >> >> > > > I would like to pitch in and help you guys, esp. with >> OpenEJB's >> >> > > > integration into Geronimo. Please let me know how I can help >> >> you. >> >> > > > >> >> > > > Knowing how valuable all your time is, I don't want to pull >> >> you away >> >> > > > from what you are doing to tutor me. But initially if you >> >> give me >> >> > > > enough hints and pointers, hopefully I'll be able to ramp up >> >> quickly. >> >> > > > >> >> > > > So please suggest areas where I can contribute and sections >> >> I can >> >> > > > tackle. Maybe I can begin by fixing some bugs for you, or >> >> implement >> >> > > > the low-priority TODOs that you have. Or maybe I can begin >> >> by doing >> >> > > > some mundane chore like running the EJB suite on G's TCK for >> >> you. >> >> > > > However you deem fit, however you think I can be of max help >> >> to you, >> >> > > > just let me know. >> >> > > > >> >> > > > Let's give this a shot and see how it goes. I hope I'll be >> >> more help >> >> > > > than hindrance to you. >> >> > > > >> >> > > > Is there an overview of the OpenEJB arch and/or build tree >> >> > > > structure somewhere ? >> >> > > > >> >> > > > Cheers >> >> > > > Prasad >> >> > > > >> >> > > >> >> > > >> >> > >> >> >> >> >> >> >> >> -- >> >> Thanks >> >> - Mohammad Nour >> >> >> > >> >> >
-- Thanks - Mohammad Nour
