You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2010/02/23 09:14:09 UTC
Re: JUnit Runner
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?
-David
Re: JUnit Runner
Posted by Mohammad Nour El-Din <no...@gmail.com>.
+1 @ Jean-Louis
On Mon, Nov 15, 2010 at 9:29 AM, Jean-Louis MONTEIRO
<je...@atosorigin.com> wrote:
>
> Hi David,
>
> From the end user point of view (at least in my company), that would be
> great to consider a test case as a no-interface view bean or so.
>
> Basically, they need to be able to inject resources, EJBs, ... as if they
> were in a stateless for example.
> The point I mean is transactions!
> De we need to deal with transactions in TestCases? IMO, no!
>
> Either way, they need something simple to increase productivity.
> Quintin's proposal was AFAIC simple.
> Your testcase is also very useful but it targets advanced people if they
> want to build their own application/module, ... (very useful to build our
> testcases for example)
>
> I would be in favor of pushing something basic and simple and wait for some
> feedback of the community.
> IMHO, it's simpler to push something simple and enhance it afterwards, than
> pushing something more complex/feature-full and having to break something in
> next releases.
>
>
> Jean-Louis
> --
> View this message in context: http://openejb.979440.n4.nabble.com/Re-JUnit-Runner-0-1-tp988903p3042736.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
--
Thanks
- Mohammad Nour
Author of (WebSphere Application Server Community Edition 2.0 User Guide)
http://www.redbooks.ibm.com/abstracts/sg247585.html
- LinkedIn: http://www.linkedin.com/in/mnour
- Blog: http://tadabborat.blogspot.com
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship
"Stay hungry, stay foolish."
- Steve Jobs
Re: JUnit Runner
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Hi David,
>From the end user point of view (at least in my company), that would be
great to consider a test case as a no-interface view bean or so.
Basically, they need to be able to inject resources, EJBs, ... as if they
were in a stateless for example.
The point I mean is transactions!
De we need to deal with transactions in TestCases? IMO, no!
Either way, they need something simple to increase productivity.
Quintin's proposal was AFAIC simple.
Your testcase is also very useful but it targets advanced people if they
want to build their own application/module, ... (very useful to build our
testcases for example)
I would be in favor of pushing something basic and simple and wait for some
feedback of the community.
IMHO, it's simpler to push something simple and enhance it afterwards, than
pushing something more complex/feature-full and having to break something in
next releases.
Jean-Louis
--
View this message in context: http://openejb.979440.n4.nabble.com/Re-JUnit-Runner-0-1-tp988903p3042736.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: JUnit Runner
Posted by David Blevins <da...@visi.com>.
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