Re: JUnit Runner 0.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: JUnit Runner 0.1

dblevins
Administrator

On Sep 27, 2009, at 12:16 PM, Quintin Beukes wrote:

> Hey,
>
> The previous runner I started modifying extensively to customize for
> our company's tests. I already had a small testing framework for the
> tests, which used Spring to initial OpenEJB and do the lookups. I
> changed this to use the runner technique.
>
> Then over the weekend I decided to extract the runner code into an
> openejb-junit project, and make it extensible so I could use the
> library's code and only extend to give our tests the same
> functionality.
>
> This is what I came up with: https://issues.apache.org/jira/browse/OPENEJB-1078
>
> The JUnit tests demonstrate it's behaviour. These 3 tests are the  
> best examples:
> org.apache.openejb.junit.TestEjbBasic
> org.apache.openejb.junit.TestEjbSecurity
> org.apache.openejb.junit.TestDualConfigOverride
>
> It supports class level configuration of the InitialContext, and then
> method specific configurations. You can configure the InitialContext
> from a file, or by directly specifying properties. You can have
> OpenEJB do any of it's supported injections, or you can have the
> runner inject the InitialContext (or it's initialization Properties
> object) and do your own lookups. You can specify as which role to load
> the InitialContext (basically a RunAs).
>
> I'm planning on doing resource configurations, such as datasources.
> Any other suggestions, please throw them my way. And please send me
> feedback. So far it's working very well for my tests. I have yet to
> complete the spring modification, but for those tests which don't
> require it, it works very well. Especially the role tests.
>
> Not that it still doesn't support JUnit 3. If you require JUnit 3, let
> me know and I'll prioritize implementing JUnit 3 support.
>
> An basic example would be the following:
> @RunWith(OpenEjbRunner.class)
> @ContextConfig(
>  properties={
>    
> @Property
> ("java
> .naming
> .factory
> .initial=org.apache.openejb.client.LocalInitialContextFactory")
>  }
> )
> @LocalClient
> public class TestEjbSecurity
> {
>  @EJB
>  private MyBusinessBean myBean;
>
>  @TestResource
>  private InitialContext currentInitialContext;
>
>  @Test
>  @ContextConfig(
>    securityRole="Admin"
>  )
>  public void testAsAdmin()
>  {
>    myBean.someMethod();
>    currentInitialContext.lookup("some/custom/lookup");
>  }
>
>  @Test
>  @ContextConfig(
>    propertiesFile="/META-INF/employee-context.properties",
>    securityRole="Employe"
>  )
>  public void testAsEmployee()
>  {
>    myBean.someMethod();
>  }
> }

Looks like a great start.  For code of this size we'll definitely need  
a CLA on file - http://apache.org/licenses/#clas

Once we get that on file, we can check this into a branch and hammer  
on it together.  I've been itching to work on this feature for a bit  
as well, so this will be fun.  Have a bunch of ideas around  
transactions, rerunning tests, and some security stuff too.  Haven't  
had a chance to look too closely at the code you've got, but initial  
glance seems like it will be a good prototype.

Do you know if TestNG has a similar Test Runner concept?


-David




Reply | Threaded
Open this post in threaded view
|

Re: JUnit Runner 0.1

Quintin Beukes-2
Glad I could be of service.

Will do the license file and upload it. Then I'll wait until it's in
SVN and just send patches. Beats uploading the whole thing to JIRA
everytime (it's small, but still feels like overkill).

Then, re. the code. I know it can use a lot of API changes. Not a lot
of time went into designing the layout. I did some quick thoughts on
it, and this is what I came up with - though it still doesn't feel
right. Would be great to see it evolve and learn from you guys.
OpenEJB's design (source level) is brilliant.

Quintin Beukes



On Tue, Sep 29, 2009 at 3:33 AM, David Blevins <[hidden email]> wrote:

> Responded on dev@
>
> On Sep 27, 2009, at 12:16 PM, Quintin Beukes wrote:
>
>> Hey,
>>
>> The previous runner I started modifying extensively to customize for
>> our company's tests. I already had a small testing framework for the
>> tests, which used Spring to initial OpenEJB and do the lookups. I
>> changed this to use the runner technique.
>>
>> Then over the weekend I decided to extract the runner code into an
>> openejb-junit project, and make it extensible so I could use the
>> library's code and only extend to give our tests the same
>> functionality.
>>
>> This is what I came up with:
>> https://issues.apache.org/jira/browse/OPENEJB-1078
>>
>> The JUnit tests demonstrate it's behaviour. These 3 tests are the best
>> examples:
>> org.apache.openejb.junit.TestEjbBasic
>> org.apache.openejb.junit.TestEjbSecurity
>> org.apache.openejb.junit.TestDualConfigOverride
>>
>> It supports class level configuration of the InitialContext, and then
>> method specific configurations. You can configure the InitialContext
>> from a file, or by directly specifying properties. You can have
>> OpenEJB do any of it's supported injections, or you can have the
>> runner inject the InitialContext (or it's initialization Properties
>> object) and do your own lookups. You can specify as which role to load
>> the InitialContext (basically a RunAs).
>>
>> I'm planning on doing resource configurations, such as datasources.
>> Any other suggestions, please throw them my way. And please send me
>> feedback. So far it's working very well for my tests. I have yet to
>> complete the spring modification, but for those tests which don't
>> require it, it works very well. Especially the role tests.
>>
>> Not that it still doesn't support JUnit 3. If you require JUnit 3, let
>> me know and I'll prioritize implementing JUnit 3 support.
>>
>> An basic example would be the following:
>> @RunWith(OpenEjbRunner.class)
>> @ContextConfig(
>>  properties={
>>
>> @Property("java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory")
>>  }
>> )
>> @LocalClient
>> public class TestEjbSecurity
>> {
>>  @EJB
>>  private MyBusinessBean myBean;
>>
>>  @TestResource
>>  private InitialContext currentInitialContext;
>>
>>  @Test
>>  @ContextConfig(
>>   securityRole="Admin"
>>  )
>>  public void testAsAdmin()
>>  {
>>   myBean.someMethod();
>>   currentInitialContext.lookup("some/custom/lookup");
>>  }
>>
>>  @Test
>>  @ContextConfig(
>>   propertiesFile="/META-INF/employee-context.properties",
>>   securityRole="Employe"
>>  )
>>  public void testAsEmployee()
>>  {
>>   myBean.someMethod();
>>  }
>> }
>>
>> Quintin Beukes
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: JUnit Runner 0.1

Quintin Beukes-2
Re. TestNG.

TestNG has factories. haven't used it, but if I recall correctly you
can have a separate class as a factory, and then just reference that
class in your configuration. So if you have a smart factory, you could
probably initialize the InitialContext and then create the test. I'll
have a look at it and see if it's possible to achieve the same power
for TestNG (ie. method level configurations and what not).

TestNG has some great features, like parallel testing and test
dependencies. These can speed up your tests a lot, especially when the
projects grows and a single failure causes you to wait 10 minutes just
to see you have 2000 tests that failed. JUnit can learn a lot from
them.

Quintin Beukes



On Tue, Sep 29, 2009 at 9:51 AM, Quintin Beukes <[hidden email]> wrote:

> Glad I could be of service.
>
> Will do the license file and upload it. Then I'll wait until it's in
> SVN and just send patches. Beats uploading the whole thing to JIRA
> everytime (it's small, but still feels like overkill).
>
> Then, re. the code. I know it can use a lot of API changes. Not a lot
> of time went into designing the layout. I did some quick thoughts on
> it, and this is what I came up with - though it still doesn't feel
> right. Would be great to see it evolve and learn from you guys.
> OpenEJB's design (source level) is brilliant.
>
> Quintin Beukes
>
>
>
> On Tue, Sep 29, 2009 at 3:33 AM, David Blevins <[hidden email]> wrote:
>> Responded on dev@
>>
>> On Sep 27, 2009, at 12:16 PM, Quintin Beukes wrote:
>>
>>> Hey,
>>>
>>> The previous runner I started modifying extensively to customize for
>>> our company's tests. I already had a small testing framework for the
>>> tests, which used Spring to initial OpenEJB and do the lookups. I
>>> changed this to use the runner technique.
>>>
>>> Then over the weekend I decided to extract the runner code into an
>>> openejb-junit project, and make it extensible so I could use the
>>> library's code and only extend to give our tests the same
>>> functionality.
>>>
>>> This is what I came up with:
>>> https://issues.apache.org/jira/browse/OPENEJB-1078
>>>
>>> The JUnit tests demonstrate it's behaviour. These 3 tests are the best
>>> examples:
>>> org.apache.openejb.junit.TestEjbBasic
>>> org.apache.openejb.junit.TestEjbSecurity
>>> org.apache.openejb.junit.TestDualConfigOverride
>>>
>>> It supports class level configuration of the InitialContext, and then
>>> method specific configurations. You can configure the InitialContext
>>> from a file, or by directly specifying properties. You can have
>>> OpenEJB do any of it's supported injections, or you can have the
>>> runner inject the InitialContext (or it's initialization Properties
>>> object) and do your own lookups. You can specify as which role to load
>>> the InitialContext (basically a RunAs).
>>>
>>> I'm planning on doing resource configurations, such as datasources.
>>> Any other suggestions, please throw them my way. And please send me
>>> feedback. So far it's working very well for my tests. I have yet to
>>> complete the spring modification, but for those tests which don't
>>> require it, it works very well. Especially the role tests.
>>>
>>> Not that it still doesn't support JUnit 3. If you require JUnit 3, let
>>> me know and I'll prioritize implementing JUnit 3 support.
>>>
>>> An basic example would be the following:
>>> @RunWith(OpenEjbRunner.class)
>>> @ContextConfig(
>>>  properties={
>>>
>>> @Property("java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory")
>>>  }
>>> )
>>> @LocalClient
>>> public class TestEjbSecurity
>>> {
>>>  @EJB
>>>  private MyBusinessBean myBean;
>>>
>>>  @TestResource
>>>  private InitialContext currentInitialContext;
>>>
>>>  @Test
>>>  @ContextConfig(
>>>   securityRole="Admin"
>>>  )
>>>  public void testAsAdmin()
>>>  {
>>>   myBean.someMethod();
>>>   currentInitialContext.lookup("some/custom/lookup");
>>>  }
>>>
>>>  @Test
>>>  @ContextConfig(
>>>   propertiesFile="/META-INF/employee-context.properties",
>>>   securityRole="Employe"
>>>  )
>>>  public void testAsEmployee()
>>>  {
>>>   myBean.someMethod();
>>>  }
>>> }
>>>
>>> Quintin Beukes
>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: JUnit Runner 0.1

Quintin Beukes-2
I added the license and changed the way security roles are specified.

I remove the securityRole option from the ContextConfig annotation,
and added a @TestSecurity annotation. I has 2 String arrays are
options, nl. authorized and unauthorized. You can use it like this:
  @TestSecurity(
    authorized={"Admin", "Payroll"},
    unauthorized={"Employee", ""}
  )

"" is treated as unauthorized (no login). This might not be ideal,
though it is not something you might test very often, and it works
well when specifed as a constant.

This can be both class and method level, but works best method level.

It basically builds a compound JUnit statement, which executes the
same test for each of those roles. The authorized executions must
succeed, and the unauthorized executions must fail with an
EJBAccessException (it's basically like annotating a test with
"@Test(expected=EJBAccessException.class)").

It forces a certain testing style when testing your security, so a
third option called "role" which takes a single string (acts the same
as authorized={"role"}) can be used to just run the test as one role,
or a separate annotation. This way you can build separate tests for
testing unauthorized access. What I am referring to here is when you
don't feel like running a whole test, preparing data and all that,
just to test the failure at the end. It will work fine, but some
people might feel it redundant, and it might leave extra data in the
database.

What I do to avoid this, with the above is split my
authorized/unauthorized into 2 tests. The first is for "authorized",
and I test it for all my authorized roles. The second is for
"unauthorized", and all it does is execute the final line. This is
what I meant with "force a certain style of testing", a style which is
different from those listed in the OpenEJB security-testing examples -
which is probably what people are used to doing. Though change towards
something more optimal isn't always bad. The question is just which is
more optimal?

I will upload the new code in about an hour. just in case I made any
more changes.

Quintin Beukes



On Tue, Sep 29, 2009 at 10:08 AM, Quintin Beukes <[hidden email]> wrote:

> Re. TestNG.
>
> TestNG has factories. haven't used it, but if I recall correctly you
> can have a separate class as a factory, and then just reference that
> class in your configuration. So if you have a smart factory, you could
> probably initialize the InitialContext and then create the test. I'll
> have a look at it and see if it's possible to achieve the same power
> for TestNG (ie. method level configurations and what not).
>
> TestNG has some great features, like parallel testing and test
> dependencies. These can speed up your tests a lot, especially when the
> projects grows and a single failure causes you to wait 10 minutes just
> to see you have 2000 tests that failed. JUnit can learn a lot from
> them.
>
> Quintin Beukes
>
>
>
> On Tue, Sep 29, 2009 at 9:51 AM, Quintin Beukes <[hidden email]> wrote:
>> Glad I could be of service.
>>
>> Will do the license file and upload it. Then I'll wait until it's in
>> SVN and just send patches. Beats uploading the whole thing to JIRA
>> everytime (it's small, but still feels like overkill).
>>
>> Then, re. the code. I know it can use a lot of API changes. Not a lot
>> of time went into designing the layout. I did some quick thoughts on
>> it, and this is what I came up with - though it still doesn't feel
>> right. Would be great to see it evolve and learn from you guys.
>> OpenEJB's design (source level) is brilliant.
>>
>> Quintin Beukes
>>
>>
>>
>> On Tue, Sep 29, 2009 at 3:33 AM, David Blevins <[hidden email]> wrote:
>>> Responded on dev@
>>>
>>> On Sep 27, 2009, at 12:16 PM, Quintin Beukes wrote:
>>>
>>>> Hey,
>>>>
>>>> The previous runner I started modifying extensively to customize for
>>>> our company's tests. I already had a small testing framework for the
>>>> tests, which used Spring to initial OpenEJB and do the lookups. I
>>>> changed this to use the runner technique.
>>>>
>>>> Then over the weekend I decided to extract the runner code into an
>>>> openejb-junit project, and make it extensible so I could use the
>>>> library's code and only extend to give our tests the same
>>>> functionality.
>>>>
>>>> This is what I came up with:
>>>> https://issues.apache.org/jira/browse/OPENEJB-1078
>>>>
>>>> The JUnit tests demonstrate it's behaviour. These 3 tests are the best
>>>> examples:
>>>> org.apache.openejb.junit.TestEjbBasic
>>>> org.apache.openejb.junit.TestEjbSecurity
>>>> org.apache.openejb.junit.TestDualConfigOverride
>>>>
>>>> It supports class level configuration of the InitialContext, and then
>>>> method specific configurations. You can configure the InitialContext
>>>> from a file, or by directly specifying properties. You can have
>>>> OpenEJB do any of it's supported injections, or you can have the
>>>> runner inject the InitialContext (or it's initialization Properties
>>>> object) and do your own lookups. You can specify as which role to load
>>>> the InitialContext (basically a RunAs).
>>>>
>>>> I'm planning on doing resource configurations, such as datasources.
>>>> Any other suggestions, please throw them my way. And please send me
>>>> feedback. So far it's working very well for my tests. I have yet to
>>>> complete the spring modification, but for those tests which don't
>>>> require it, it works very well. Especially the role tests.
>>>>
>>>> Not that it still doesn't support JUnit 3. If you require JUnit 3, let
>>>> me know and I'll prioritize implementing JUnit 3 support.
>>>>
>>>> An basic example would be the following:
>>>> @RunWith(OpenEjbRunner.class)
>>>> @ContextConfig(
>>>>  properties={
>>>>
>>>> @Property("java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory")
>>>>  }
>>>> )
>>>> @LocalClient
>>>> public class TestEjbSecurity
>>>> {
>>>>  @EJB
>>>>  private MyBusinessBean myBean;
>>>>
>>>>  @TestResource
>>>>  private InitialContext currentInitialContext;
>>>>
>>>>  @Test
>>>>  @ContextConfig(
>>>>   securityRole="Admin"
>>>>  )
>>>>  public void testAsAdmin()
>>>>  {
>>>>   myBean.someMethod();
>>>>   currentInitialContext.lookup("some/custom/lookup");
>>>>  }
>>>>
>>>>  @Test
>>>>  @ContextConfig(
>>>>   propertiesFile="/META-INF/employee-context.properties",
>>>>   securityRole="Employe"
>>>>  )
>>>>  public void testAsEmployee()
>>>>  {
>>>>   myBean.someMethod();
>>>>  }
>>>> }
>>>>
>>>> Quintin Beukes
>>>>
>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: JUnit Runner 0.1

Quintin Beukes-2
OK. Uploaded the mentioned one. Also added a @RunTestAs annotation,
which is used similar to @RunAs.

There is one bug with the TestSecurity, when "unauthorized" property
contains only a "", ie. "guest" user. Will fix it tonight.

Quintin Beukes



On Tue, Sep 29, 2009 at 4:00 PM, Quintin Beukes <[hidden email]> wrote:

> I added the license and changed the way security roles are specified.
>
> I remove the securityRole option from the ContextConfig annotation,
> and added a @TestSecurity annotation. I has 2 String arrays are
> options, nl. authorized and unauthorized. You can use it like this:
>  @TestSecurity(
>    authorized={"Admin", "Payroll"},
>    unauthorized={"Employee", ""}
>  )
>
> "" is treated as unauthorized (no login). This might not be ideal,
> though it is not something you might test very often, and it works
> well when specifed as a constant.
>
> This can be both class and method level, but works best method level.
>
> It basically builds a compound JUnit statement, which executes the
> same test for each of those roles. The authorized executions must
> succeed, and the unauthorized executions must fail with an
> EJBAccessException (it's basically like annotating a test with
> "@Test(expected=EJBAccessException.class)").
>
> It forces a certain testing style when testing your security, so a
> third option called "role" which takes a single string (acts the same
> as authorized={"role"}) can be used to just run the test as one role,
> or a separate annotation. This way you can build separate tests for
> testing unauthorized access. What I am referring to here is when you
> don't feel like running a whole test, preparing data and all that,
> just to test the failure at the end. It will work fine, but some
> people might feel it redundant, and it might leave extra data in the
> database.
>
> What I do to avoid this, with the above is split my
> authorized/unauthorized into 2 tests. The first is for "authorized",
> and I test it for all my authorized roles. The second is for
> "unauthorized", and all it does is execute the final line. This is
> what I meant with "force a certain style of testing", a style which is
> different from those listed in the OpenEJB security-testing examples -
> which is probably what people are used to doing. Though change towards
> something more optimal isn't always bad. The question is just which is
> more optimal?
>
> I will upload the new code in about an hour. just in case I made any
> more changes.
>
> Quintin Beukes
>
>
>
> On Tue, Sep 29, 2009 at 10:08 AM, Quintin Beukes <[hidden email]> wrote:
>> Re. TestNG.
>>
>> TestNG has factories. haven't used it, but if I recall correctly you
>> can have a separate class as a factory, and then just reference that
>> class in your configuration. So if you have a smart factory, you could
>> probably initialize the InitialContext and then create the test. I'll
>> have a look at it and see if it's possible to achieve the same power
>> for TestNG (ie. method level configurations and what not).
>>
>> TestNG has some great features, like parallel testing and test
>> dependencies. These can speed up your tests a lot, especially when the
>> projects grows and a single failure causes you to wait 10 minutes just
>> to see you have 2000 tests that failed. JUnit can learn a lot from
>> them.
>>
>> Quintin Beukes
>>
>>
>>
>> On Tue, Sep 29, 2009 at 9:51 AM, Quintin Beukes <[hidden email]> wrote:
>>> Glad I could be of service.
>>>
>>> Will do the license file and upload it. Then I'll wait until it's in
>>> SVN and just send patches. Beats uploading the whole thing to JIRA
>>> everytime (it's small, but still feels like overkill).
>>>
>>> Then, re. the code. I know it can use a lot of API changes. Not a lot
>>> of time went into designing the layout. I did some quick thoughts on
>>> it, and this is what I came up with - though it still doesn't feel
>>> right. Would be great to see it evolve and learn from you guys.
>>> OpenEJB's design (source level) is brilliant.
>>>
>>> Quintin Beukes
>>>
>>>
>>>
>>> On Tue, Sep 29, 2009 at 3:33 AM, David Blevins <[hidden email]> wrote:
>>>> Responded on dev@
>>>>
>>>> On Sep 27, 2009, at 12:16 PM, Quintin Beukes wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> The previous runner I started modifying extensively to customize for
>>>>> our company's tests. I already had a small testing framework for the
>>>>> tests, which used Spring to initial OpenEJB and do the lookups. I
>>>>> changed this to use the runner technique.
>>>>>
>>>>> Then over the weekend I decided to extract the runner code into an
>>>>> openejb-junit project, and make it extensible so I could use the
>>>>> library's code and only extend to give our tests the same
>>>>> functionality.
>>>>>
>>>>> This is what I came up with:
>>>>> https://issues.apache.org/jira/browse/OPENEJB-1078
>>>>>
>>>>> The JUnit tests demonstrate it's behaviour. These 3 tests are the best
>>>>> examples:
>>>>> org.apache.openejb.junit.TestEjbBasic
>>>>> org.apache.openejb.junit.TestEjbSecurity
>>>>> org.apache.openejb.junit.TestDualConfigOverride
>>>>>
>>>>> It supports class level configuration of the InitialContext, and then
>>>>> method specific configurations. You can configure the InitialContext
>>>>> from a file, or by directly specifying properties. You can have
>>>>> OpenEJB do any of it's supported injections, or you can have the
>>>>> runner inject the InitialContext (or it's initialization Properties
>>>>> object) and do your own lookups. You can specify as which role to load
>>>>> the InitialContext (basically a RunAs).
>>>>>
>>>>> I'm planning on doing resource configurations, such as datasources.
>>>>> Any other suggestions, please throw them my way. And please send me
>>>>> feedback. So far it's working very well for my tests. I have yet to
>>>>> complete the spring modification, but for those tests which don't
>>>>> require it, it works very well. Especially the role tests.
>>>>>
>>>>> Not that it still doesn't support JUnit 3. If you require JUnit 3, let
>>>>> me know and I'll prioritize implementing JUnit 3 support.
>>>>>
>>>>> An basic example would be the following:
>>>>> @RunWith(OpenEjbRunner.class)
>>>>> @ContextConfig(
>>>>>  properties={
>>>>>
>>>>> @Property("java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory")
>>>>>  }
>>>>> )
>>>>> @LocalClient
>>>>> public class TestEjbSecurity
>>>>> {
>>>>>  @EJB
>>>>>  private MyBusinessBean myBean;
>>>>>
>>>>>  @TestResource
>>>>>  private InitialContext currentInitialContext;
>>>>>
>>>>>  @Test
>>>>>  @ContextConfig(
>>>>>   securityRole="Admin"
>>>>>  )
>>>>>  public void testAsAdmin()
>>>>>  {
>>>>>   myBean.someMethod();
>>>>>   currentInitialContext.lookup("some/custom/lookup");
>>>>>  }
>>>>>
>>>>>  @Test
>>>>>  @ContextConfig(
>>>>>   propertiesFile="/META-INF/employee-context.properties",
>>>>>   securityRole="Employe"
>>>>>  )
>>>>>  public void testAsEmployee()
>>>>>  {
>>>>>   myBean.someMethod();
>>>>>  }
>>>>> }
>>>>>
>>>>> Quintin Beukes
>>>>>
>>>>
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: JUnit Runner 0.1

Quintin Beukes-2
The bug is solved. Haven't uploaded it again. Will do so this afternoon.

Added a constant: TestSecurity.UNAUTHENTICATED. It basically equals
"". You can use that as follows:

@Test
@TestSecurity(
  authorized={"Admin", "Payroll"},
  unauthorized={"Employee", TestSecurity.UNAUTHENTICATED}
)
public void testAddEmployee()
{
  ...
}

Quintin Beukes



On Tue, Sep 29, 2009 at 5:12 PM, Quintin Beukes <[hidden email]> wrote:

> OK. Uploaded the mentioned one. Also added a @RunTestAs annotation,
> which is used similar to @RunAs.
>
> There is one bug with the TestSecurity, when "unauthorized" property
> contains only a "", ie. "guest" user. Will fix it tonight.
>
> Quintin Beukes
>
>
>
> On Tue, Sep 29, 2009 at 4:00 PM, Quintin Beukes <[hidden email]> wrote:
>> I added the license and changed the way security roles are specified.
>>
>> I remove the securityRole option from the ContextConfig annotation,
>> and added a @TestSecurity annotation. I has 2 String arrays are
>> options, nl. authorized and unauthorized. You can use it like this:
>>  @TestSecurity(
>>    authorized={"Admin", "Payroll"},
>>    unauthorized={"Employee", ""}
>>  )
>>
>> "" is treated as unauthorized (no login). This might not be ideal,
>> though it is not something you might test very often, and it works
>> well when specifed as a constant.
>>
>> This can be both class and method level, but works best method level.
>>
>> It basically builds a compound JUnit statement, which executes the
>> same test for each of those roles. The authorized executions must
>> succeed, and the unauthorized executions must fail with an
>> EJBAccessException (it's basically like annotating a test with
>> "@Test(expected=EJBAccessException.class)").
>>
>> It forces a certain testing style when testing your security, so a
>> third option called "role" which takes a single string (acts the same
>> as authorized={"role"}) can be used to just run the test as one role,
>> or a separate annotation. This way you can build separate tests for
>> testing unauthorized access. What I am referring to here is when you
>> don't feel like running a whole test, preparing data and all that,
>> just to test the failure at the end. It will work fine, but some
>> people might feel it redundant, and it might leave extra data in the
>> database.
>>
>> What I do to avoid this, with the above is split my
>> authorized/unauthorized into 2 tests. The first is for "authorized",
>> and I test it for all my authorized roles. The second is for
>> "unauthorized", and all it does is execute the final line. This is
>> what I meant with "force a certain style of testing", a style which is
>> different from those listed in the OpenEJB security-testing examples -
>> which is probably what people are used to doing. Though change towards
>> something more optimal isn't always bad. The question is just which is
>> more optimal?
>>
>> I will upload the new code in about an hour. just in case I made any
>> more changes.
>>
>> Quintin Beukes
>>
>>
>>
>> On Tue, Sep 29, 2009 at 10:08 AM, Quintin Beukes <[hidden email]> wrote:
>>> Re. TestNG.
>>>
>>> TestNG has factories. haven't used it, but if I recall correctly you
>>> can have a separate class as a factory, and then just reference that
>>> class in your configuration. So if you have a smart factory, you could
>>> probably initialize the InitialContext and then create the test. I'll
>>> have a look at it and see if it's possible to achieve the same power
>>> for TestNG (ie. method level configurations and what not).
>>>
>>> TestNG has some great features, like parallel testing and test
>>> dependencies. These can speed up your tests a lot, especially when the
>>> projects grows and a single failure causes you to wait 10 minutes just
>>> to see you have 2000 tests that failed. JUnit can learn a lot from
>>> them.
>>>
>>> Quintin Beukes
>>>
>>>
>>>
>>> On Tue, Sep 29, 2009 at 9:51 AM, Quintin Beukes <[hidden email]> wrote:
>>>> Glad I could be of service.
>>>>
>>>> Will do the license file and upload it. Then I'll wait until it's in
>>>> SVN and just send patches. Beats uploading the whole thing to JIRA
>>>> everytime (it's small, but still feels like overkill).
>>>>
>>>> Then, re. the code. I know it can use a lot of API changes. Not a lot
>>>> of time went into designing the layout. I did some quick thoughts on
>>>> it, and this is what I came up with - though it still doesn't feel
>>>> right. Would be great to see it evolve and learn from you guys.
>>>> OpenEJB's design (source level) is brilliant.
>>>>
>>>> Quintin Beukes
>>>>
>>>>
>>>>
>>>> On Tue, Sep 29, 2009 at 3:33 AM, David Blevins <[hidden email]> wrote:
>>>>> Responded on dev@
>>>>>
>>>>> On Sep 27, 2009, at 12:16 PM, Quintin Beukes wrote:
>>>>>
>>>>>> Hey,
>>>>>>
>>>>>> The previous runner I started modifying extensively to customize for
>>>>>> our company's tests. I already had a small testing framework for the
>>>>>> tests, which used Spring to initial OpenEJB and do the lookups. I
>>>>>> changed this to use the runner technique.
>>>>>>
>>>>>> Then over the weekend I decided to extract the runner code into an
>>>>>> openejb-junit project, and make it extensible so I could use the
>>>>>> library's code and only extend to give our tests the same
>>>>>> functionality.
>>>>>>
>>>>>> This is what I came up with:
>>>>>> https://issues.apache.org/jira/browse/OPENEJB-1078
>>>>>>
>>>>>> The JUnit tests demonstrate it's behaviour. These 3 tests are the best
>>>>>> examples:
>>>>>> org.apache.openejb.junit.TestEjbBasic
>>>>>> org.apache.openejb.junit.TestEjbSecurity
>>>>>> org.apache.openejb.junit.TestDualConfigOverride
>>>>>>
>>>>>> It supports class level configuration of the InitialContext, and then
>>>>>> method specific configurations. You can configure the InitialContext
>>>>>> from a file, or by directly specifying properties. You can have
>>>>>> OpenEJB do any of it's supported injections, or you can have the
>>>>>> runner inject the InitialContext (or it's initialization Properties
>>>>>> object) and do your own lookups. You can specify as which role to load
>>>>>> the InitialContext (basically a RunAs).
>>>>>>
>>>>>> I'm planning on doing resource configurations, such as datasources.
>>>>>> Any other suggestions, please throw them my way. And please send me
>>>>>> feedback. So far it's working very well for my tests. I have yet to
>>>>>> complete the spring modification, but for those tests which don't
>>>>>> require it, it works very well. Especially the role tests.
>>>>>>
>>>>>> Not that it still doesn't support JUnit 3. If you require JUnit 3, let
>>>>>> me know and I'll prioritize implementing JUnit 3 support.
>>>>>>
>>>>>> An basic example would be the following:
>>>>>> @RunWith(OpenEjbRunner.class)
>>>>>> @ContextConfig(
>>>>>>  properties={
>>>>>>
>>>>>> @Property("java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory")
>>>>>>  }
>>>>>> )
>>>>>> @LocalClient
>>>>>> public class TestEjbSecurity
>>>>>> {
>>>>>>  @EJB
>>>>>>  private MyBusinessBean myBean;
>>>>>>
>>>>>>  @TestResource
>>>>>>  private InitialContext currentInitialContext;
>>>>>>
>>>>>>  @Test
>>>>>>  @ContextConfig(
>>>>>>   securityRole="Admin"
>>>>>>  )
>>>>>>  public void testAsAdmin()
>>>>>>  {
>>>>>>   myBean.someMethod();
>>>>>>   currentInitialContext.lookup("some/custom/lookup");
>>>>>>  }
>>>>>>
>>>>>>  @Test
>>>>>>  @ContextConfig(
>>>>>>   propertiesFile="/META-INF/employee-context.properties",
>>>>>>   securityRole="Employe"
>>>>>>  )
>>>>>>  public void testAsEmployee()
>>>>>>  {
>>>>>>   myBean.someMethod();
>>>>>>  }
>>>>>> }
>>>>>>
>>>>>> Quintin Beukes
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: JUnit Runner 0.1

Quintin Beukes-2
I must say that writing my tests go much quicker now, and that
compared to before the runner they are MUCH shorter. I had a lot of
extra code for all the different security role tests. Those
@TestSecurity and @RunTestAs annotations help a lot.

Quintin Beukes



On Wed, Sep 30, 2009 at 11:10 AM, Quintin Beukes <[hidden email]> wrote:

> The bug is solved. Haven't uploaded it again. Will do so this afternoon.
>
> Added a constant: TestSecurity.UNAUTHENTICATED. It basically equals
> "". You can use that as follows:
>
> @Test
> @TestSecurity(
>  authorized={"Admin", "Payroll"},
>  unauthorized={"Employee", TestSecurity.UNAUTHENTICATED}
> )
> public void testAddEmployee()
> {
>  ...
> }
>
> Quintin Beukes
>
>
>
> On Tue, Sep 29, 2009 at 5:12 PM, Quintin Beukes <[hidden email]> wrote:
>> OK. Uploaded the mentioned one. Also added a @RunTestAs annotation,
>> which is used similar to @RunAs.
>>
>> There is one bug with the TestSecurity, when "unauthorized" property
>> contains only a "", ie. "guest" user. Will fix it tonight.
>>
>> Quintin Beukes
>>
>>
>>
>> On Tue, Sep 29, 2009 at 4:00 PM, Quintin Beukes <[hidden email]> wrote:
>>> I added the license and changed the way security roles are specified.
>>>
>>> I remove the securityRole option from the ContextConfig annotation,
>>> and added a @TestSecurity annotation. I has 2 String arrays are
>>> options, nl. authorized and unauthorized. You can use it like this:
>>>  @TestSecurity(
>>>    authorized={"Admin", "Payroll"},
>>>    unauthorized={"Employee", ""}
>>>  )
>>>
>>> "" is treated as unauthorized (no login). This might not be ideal,
>>> though it is not something you might test very often, and it works
>>> well when specifed as a constant.
>>>
>>> This can be both class and method level, but works best method level.
>>>
>>> It basically builds a compound JUnit statement, which executes the
>>> same test for each of those roles. The authorized executions must
>>> succeed, and the unauthorized executions must fail with an
>>> EJBAccessException (it's basically like annotating a test with
>>> "@Test(expected=EJBAccessException.class)").
>>>
>>> It forces a certain testing style when testing your security, so a
>>> third option called "role" which takes a single string (acts the same
>>> as authorized={"role"}) can be used to just run the test as one role,
>>> or a separate annotation. This way you can build separate tests for
>>> testing unauthorized access. What I am referring to here is when you
>>> don't feel like running a whole test, preparing data and all that,
>>> just to test the failure at the end. It will work fine, but some
>>> people might feel it redundant, and it might leave extra data in the
>>> database.
>>>
>>> What I do to avoid this, with the above is split my
>>> authorized/unauthorized into 2 tests. The first is for "authorized",
>>> and I test it for all my authorized roles. The second is for
>>> "unauthorized", and all it does is execute the final line. This is
>>> what I meant with "force a certain style of testing", a style which is
>>> different from those listed in the OpenEJB security-testing examples -
>>> which is probably what people are used to doing. Though change towards
>>> something more optimal isn't always bad. The question is just which is
>>> more optimal?
>>>
>>> I will upload the new code in about an hour. just in case I made any
>>> more changes.
>>>
>>> Quintin Beukes
>>>
>>>
>>>
>>> On Tue, Sep 29, 2009 at 10:08 AM, Quintin Beukes <[hidden email]> wrote:
>>>> Re. TestNG.
>>>>
>>>> TestNG has factories. haven't used it, but if I recall correctly you
>>>> can have a separate class as a factory, and then just reference that
>>>> class in your configuration. So if you have a smart factory, you could
>>>> probably initialize the InitialContext and then create the test. I'll
>>>> have a look at it and see if it's possible to achieve the same power
>>>> for TestNG (ie. method level configurations and what not).
>>>>
>>>> TestNG has some great features, like parallel testing and test
>>>> dependencies. These can speed up your tests a lot, especially when the
>>>> projects grows and a single failure causes you to wait 10 minutes just
>>>> to see you have 2000 tests that failed. JUnit can learn a lot from
>>>> them.
>>>>
>>>> Quintin Beukes
>>>>
>>>>
>>>>
>>>> On Tue, Sep 29, 2009 at 9:51 AM, Quintin Beukes <[hidden email]> wrote:
>>>>> Glad I could be of service.
>>>>>
>>>>> Will do the license file and upload it. Then I'll wait until it's in
>>>>> SVN and just send patches. Beats uploading the whole thing to JIRA
>>>>> everytime (it's small, but still feels like overkill).
>>>>>
>>>>> Then, re. the code. I know it can use a lot of API changes. Not a lot
>>>>> of time went into designing the layout. I did some quick thoughts on
>>>>> it, and this is what I came up with - though it still doesn't feel
>>>>> right. Would be great to see it evolve and learn from you guys.
>>>>> OpenEJB's design (source level) is brilliant.
>>>>>
>>>>> Quintin Beukes
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 29, 2009 at 3:33 AM, David Blevins <[hidden email]> wrote:
>>>>>> Responded on dev@
>>>>>>
>>>>>> On Sep 27, 2009, at 12:16 PM, Quintin Beukes wrote:
>>>>>>
>>>>>>> Hey,
>>>>>>>
>>>>>>> The previous runner I started modifying extensively to customize for
>>>>>>> our company's tests. I already had a small testing framework for the
>>>>>>> tests, which used Spring to initial OpenEJB and do the lookups. I
>>>>>>> changed this to use the runner technique.
>>>>>>>
>>>>>>> Then over the weekend I decided to extract the runner code into an
>>>>>>> openejb-junit project, and make it extensible so I could use the
>>>>>>> library's code and only extend to give our tests the same
>>>>>>> functionality.
>>>>>>>
>>>>>>> This is what I came up with:
>>>>>>> https://issues.apache.org/jira/browse/OPENEJB-1078
>>>>>>>
>>>>>>> The JUnit tests demonstrate it's behaviour. These 3 tests are the best
>>>>>>> examples:
>>>>>>> org.apache.openejb.junit.TestEjbBasic
>>>>>>> org.apache.openejb.junit.TestEjbSecurity
>>>>>>> org.apache.openejb.junit.TestDualConfigOverride
>>>>>>>
>>>>>>> It supports class level configuration of the InitialContext, and then
>>>>>>> method specific configurations. You can configure the InitialContext
>>>>>>> from a file, or by directly specifying properties. You can have
>>>>>>> OpenEJB do any of it's supported injections, or you can have the
>>>>>>> runner inject the InitialContext (or it's initialization Properties
>>>>>>> object) and do your own lookups. You can specify as which role to load
>>>>>>> the InitialContext (basically a RunAs).
>>>>>>>
>>>>>>> I'm planning on doing resource configurations, such as datasources.
>>>>>>> Any other suggestions, please throw them my way. And please send me
>>>>>>> feedback. So far it's working very well for my tests. I have yet to
>>>>>>> complete the spring modification, but for those tests which don't
>>>>>>> require it, it works very well. Especially the role tests.
>>>>>>>
>>>>>>> Not that it still doesn't support JUnit 3. If you require JUnit 3, let
>>>>>>> me know and I'll prioritize implementing JUnit 3 support.
>>>>>>>
>>>>>>> An basic example would be the following:
>>>>>>> @RunWith(OpenEjbRunner.class)
>>>>>>> @ContextConfig(
>>>>>>>  properties={
>>>>>>>
>>>>>>> @Property("java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory")
>>>>>>>  }
>>>>>>> )
>>>>>>> @LocalClient
>>>>>>> public class TestEjbSecurity
>>>>>>> {
>>>>>>>  @EJB
>>>>>>>  private MyBusinessBean myBean;
>>>>>>>
>>>>>>>  @TestResource
>>>>>>>  private InitialContext currentInitialContext;
>>>>>>>
>>>>>>>  @Test
>>>>>>>  @ContextConfig(
>>>>>>>   securityRole="Admin"
>>>>>>>  )
>>>>>>>  public void testAsAdmin()
>>>>>>>  {
>>>>>>>   myBean.someMethod();
>>>>>>>   currentInitialContext.lookup("some/custom/lookup");
>>>>>>>  }
>>>>>>>
>>>>>>>  @Test
>>>>>>>  @ContextConfig(
>>>>>>>   propertiesFile="/META-INF/employee-context.properties",
>>>>>>>   securityRole="Employe"
>>>>>>>  )
>>>>>>>  public void testAsEmployee()
>>>>>>>  {
>>>>>>>   myBean.someMethod();
>>>>>>>  }
>>>>>>> }
>>>>>>>
>>>>>>> Quintin Beukes
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: JUnit Runner 0.1

Quintin Beukes-2
Uploaded another one. So far this one seems to be doing the trick.

All our tests on the current project have been changed to using this,
and it's DEFINITELY, without doubt helping.

I feel it can use a lot more work, and ideas would be great.

Just let me know what you're thinking, and any design ideas and I'll have at it.

Quintin Beukes



On Wed, Sep 30, 2009 at 2:53 PM, Quintin Beukes <[hidden email]> wrote:

> I must say that writing my tests go much quicker now, and that
> compared to before the runner they are MUCH shorter. I had a lot of
> extra code for all the different security role tests. Those
> @TestSecurity and @RunTestAs annotations help a lot.
>
> Quintin Beukes
>
>
>
> On Wed, Sep 30, 2009 at 11:10 AM, Quintin Beukes <[hidden email]> wrote:
>> The bug is solved. Haven't uploaded it again. Will do so this afternoon.
>>
>> Added a constant: TestSecurity.UNAUTHENTICATED. It basically equals
>> "". You can use that as follows:
>>
>> @Test
>> @TestSecurity(
>>  authorized={"Admin", "Payroll"},
>>  unauthorized={"Employee", TestSecurity.UNAUTHENTICATED}
>> )
>> public void testAddEmployee()
>> {
>>  ...
>> }
>>
>> Quintin Beukes
>>
>>
>>
>> On Tue, Sep 29, 2009 at 5:12 PM, Quintin Beukes <[hidden email]> wrote:
>>> OK. Uploaded the mentioned one. Also added a @RunTestAs annotation,
>>> which is used similar to @RunAs.
>>>
>>> There is one bug with the TestSecurity, when "unauthorized" property
>>> contains only a "", ie. "guest" user. Will fix it tonight.
>>>
>>> Quintin Beukes
>>>
>>>
>>>
>>> On Tue, Sep 29, 2009 at 4:00 PM, Quintin Beukes <[hidden email]> wrote:
>>>> I added the license and changed the way security roles are specified.
>>>>
>>>> I remove the securityRole option from the ContextConfig annotation,
>>>> and added a @TestSecurity annotation. I has 2 String arrays are
>>>> options, nl. authorized and unauthorized. You can use it like this:
>>>>  @TestSecurity(
>>>>    authorized={"Admin", "Payroll"},
>>>>    unauthorized={"Employee", ""}
>>>>  )
>>>>
>>>> "" is treated as unauthorized (no login). This might not be ideal,
>>>> though it is not something you might test very often, and it works
>>>> well when specifed as a constant.
>>>>
>>>> This can be both class and method level, but works best method level.
>>>>
>>>> It basically builds a compound JUnit statement, which executes the
>>>> same test for each of those roles. The authorized executions must
>>>> succeed, and the unauthorized executions must fail with an
>>>> EJBAccessException (it's basically like annotating a test with
>>>> "@Test(expected=EJBAccessException.class)").
>>>>
>>>> It forces a certain testing style when testing your security, so a
>>>> third option called "role" which takes a single string (acts the same
>>>> as authorized={"role"}) can be used to just run the test as one role,
>>>> or a separate annotation. This way you can build separate tests for
>>>> testing unauthorized access. What I am referring to here is when you
>>>> don't feel like running a whole test, preparing data and all that,
>>>> just to test the failure at the end. It will work fine, but some
>>>> people might feel it redundant, and it might leave extra data in the
>>>> database.
>>>>
>>>> What I do to avoid this, with the above is split my
>>>> authorized/unauthorized into 2 tests. The first is for "authorized",
>>>> and I test it for all my authorized roles. The second is for
>>>> "unauthorized", and all it does is execute the final line. This is
>>>> what I meant with "force a certain style of testing", a style which is
>>>> different from those listed in the OpenEJB security-testing examples -
>>>> which is probably what people are used to doing. Though change towards
>>>> something more optimal isn't always bad. The question is just which is
>>>> more optimal?
>>>>
>>>> I will upload the new code in about an hour. just in case I made any
>>>> more changes.
>>>>
>>>> Quintin Beukes
>>>>
>>>>
>>>>
>>>> On Tue, Sep 29, 2009 at 10:08 AM, Quintin Beukes <[hidden email]> wrote:
>>>>> Re. TestNG.
>>>>>
>>>>> TestNG has factories. haven't used it, but if I recall correctly you
>>>>> can have a separate class as a factory, and then just reference that
>>>>> class in your configuration. So if you have a smart factory, you could
>>>>> probably initialize the InitialContext and then create the test. I'll
>>>>> have a look at it and see if it's possible to achieve the same power
>>>>> for TestNG (ie. method level configurations and what not).
>>>>>
>>>>> TestNG has some great features, like parallel testing and test
>>>>> dependencies. These can speed up your tests a lot, especially when the
>>>>> projects grows and a single failure causes you to wait 10 minutes just
>>>>> to see you have 2000 tests that failed. JUnit can learn a lot from
>>>>> them.
>>>>>
>>>>> Quintin Beukes
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 29, 2009 at 9:51 AM, Quintin Beukes <[hidden email]> wrote:
>>>>>> Glad I could be of service.
>>>>>>
>>>>>> Will do the license file and upload it. Then I'll wait until it's in
>>>>>> SVN and just send patches. Beats uploading the whole thing to JIRA
>>>>>> everytime (it's small, but still feels like overkill).
>>>>>>
>>>>>> Then, re. the code. I know it can use a lot of API changes. Not a lot
>>>>>> of time went into designing the layout. I did some quick thoughts on
>>>>>> it, and this is what I came up with - though it still doesn't feel
>>>>>> right. Would be great to see it evolve and learn from you guys.
>>>>>> OpenEJB's design (source level) is brilliant.
>>>>>>
>>>>>> Quintin Beukes
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 29, 2009 at 3:33 AM, David Blevins <[hidden email]> wrote:
>>>>>>> Responded on dev@
>>>>>>>
>>>>>>> On Sep 27, 2009, at 12:16 PM, Quintin Beukes wrote:
>>>>>>>
>>>>>>>> Hey,
>>>>>>>>
>>>>>>>> The previous runner I started modifying extensively to customize for
>>>>>>>> our company's tests. I already had a small testing framework for the
>>>>>>>> tests, which used Spring to initial OpenEJB and do the lookups. I
>>>>>>>> changed this to use the runner technique.
>>>>>>>>
>>>>>>>> Then over the weekend I decided to extract the runner code into an
>>>>>>>> openejb-junit project, and make it extensible so I could use the
>>>>>>>> library's code and only extend to give our tests the same
>>>>>>>> functionality.
>>>>>>>>
>>>>>>>> This is what I came up with:
>>>>>>>> https://issues.apache.org/jira/browse/OPENEJB-1078
>>>>>>>>
>>>>>>>> The JUnit tests demonstrate it's behaviour. These 3 tests are the best
>>>>>>>> examples:
>>>>>>>> org.apache.openejb.junit.TestEjbBasic
>>>>>>>> org.apache.openejb.junit.TestEjbSecurity
>>>>>>>> org.apache.openejb.junit.TestDualConfigOverride
>>>>>>>>
>>>>>>>> It supports class level configuration of the InitialContext, and then
>>>>>>>> method specific configurations. You can configure the InitialContext
>>>>>>>> from a file, or by directly specifying properties. You can have
>>>>>>>> OpenEJB do any of it's supported injections, or you can have the
>>>>>>>> runner inject the InitialContext (or it's initialization Properties
>>>>>>>> object) and do your own lookups. You can specify as which role to load
>>>>>>>> the InitialContext (basically a RunAs).
>>>>>>>>
>>>>>>>> I'm planning on doing resource configurations, such as datasources.
>>>>>>>> Any other suggestions, please throw them my way. And please send me
>>>>>>>> feedback. So far it's working very well for my tests. I have yet to
>>>>>>>> complete the spring modification, but for those tests which don't
>>>>>>>> require it, it works very well. Especially the role tests.
>>>>>>>>
>>>>>>>> Not that it still doesn't support JUnit 3. If you require JUnit 3, let
>>>>>>>> me know and I'll prioritize implementing JUnit 3 support.
>>>>>>>>
>>>>>>>> An basic example would be the following:
>>>>>>>> @RunWith(OpenEjbRunner.class)
>>>>>>>> @ContextConfig(
>>>>>>>>  properties={
>>>>>>>>
>>>>>>>> @Property("java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory")
>>>>>>>>  }
>>>>>>>> )
>>>>>>>> @LocalClient
>>>>>>>> public class TestEjbSecurity
>>>>>>>> {
>>>>>>>>  @EJB
>>>>>>>>  private MyBusinessBean myBean;
>>>>>>>>
>>>>>>>>  @TestResource
>>>>>>>>  private InitialContext currentInitialContext;
>>>>>>>>
>>>>>>>>  @Test
>>>>>>>>  @ContextConfig(
>>>>>>>>   securityRole="Admin"
>>>>>>>>  )
>>>>>>>>  public void testAsAdmin()
>>>>>>>>  {
>>>>>>>>   myBean.someMethod();
>>>>>>>>   currentInitialContext.lookup("some/custom/lookup");
>>>>>>>>  }
>>>>>>>>
>>>>>>>>  @Test
>>>>>>>>  @ContextConfig(
>>>>>>>>   propertiesFile="/META-INF/employee-context.properties",
>>>>>>>>   securityRole="Employe"
>>>>>>>>  )
>>>>>>>>  public void testAsEmployee()
>>>>>>>>  {
>>>>>>>>   myBean.someMethod();
>>>>>>>>  }
>>>>>>>> }
>>>>>>>>
>>>>>>>> Quintin Beukes
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Fwd: Re: JUnit Runner 0.1

Quintin Beukes
In reply to this post by dblevins
Sorry, meant to send this to the list.


---------- Forwarded message ----------
From: Quintin Beukes <[hidden email]>
Date: Fri, Oct 30, 2009 at 10:06 PM
Subject: Re: JUnit Runner 0.1
To: David Blevins <[hidden email]>


re. this.

As you probably noticed the source formatting is very different from that of
OpenEJB. Eclipse has a code formatter/cleanup feature. Feel free to run it
and reformat the code according to OpenEJB standards.

I'm not used to developing in other styles. Where ever I work the styles are
usually decided by myself, so I'm used to a certain style. Whenever I work
on Geronimo/OpenEJB code I keep having to reformat when I notice this.
Having worked from a clean code base for the JUnit runner there wasn't any
reminders. I actually only thought of it now when I jumped into the source
code.

Quintin Beukes
Reply | Threaded
Open this post in threaded view
|

Re: Re: JUnit Runner 0.1

Quintin Beukes
Re. this.

Is there anything you want changed on it? Any designs/features? I'm looking
for something to do over the weekend. I have to do a certain amount of
programming to keep my emotional level high :>

As you also probably noticed, I heavily commented it. I tried to explain
what everything does. It's a bit over the top, but the JUnit runner design
isn't very flexible if you want to keep to good OOP principals. A lot of
innovation and maturity will be needed to have it even close to as
modular/flexible as OpenEJB. So to accommodate for this I added many
comments to describe it.

It's not a very nice design. It works, though I keep feeling like it's a
mess, and wanting to rewrite it. Though, it's difficult to think of ways to
keep it modular and extensible without too much effort from the user into
using it.

Quintin Beukes


On Fri, Oct 30, 2009 at 10:08 PM, Quintin Beukes <[hidden email]>wrote:

> Sorry, meant to send this to the list.
>
>
> ---------- Forwarded message ----------
> From: Quintin Beukes <[hidden email]>
> Date: Fri, Oct 30, 2009 at 10:06 PM
> Subject: Re: JUnit Runner 0.1
> To: David Blevins <[hidden email]>
>
>
> re. this.
>
> As you probably noticed the source formatting is very different from that
> of OpenEJB. Eclipse has a code formatter/cleanup feature. Feel free to run
> it and reformat the code according to OpenEJB standards.
>
> I'm not used to developing in other styles. Where ever I work the styles
> are usually decided by myself, so I'm used to a certain style. Whenever I
> work on Geronimo/OpenEJB code I keep having to reformat when I notice this.
> Having worked from a clean code base for the JUnit runner there wasn't any
> reminders. I actually only thought of it now when I jumped into the source
> code.
>
> Quintin Beukes
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: JUnit Runner

dblevins
Administrator
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



Reply | Threaded
Open this post in threaded view
|

Re: JUnit Runner

dblevins
Administrator

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


Reply | Threaded
Open this post in threaded view
|

Re: JUnit Runner

Jean-Louis MONTEIRO
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
   --
    Jean-Louis Monteiro
    http://twitter.com/jlouismonteiro
    http://www.tomitribe.com
Reply | Threaded
Open this post in threaded view
|

Re: JUnit Runner

Mohammad Nour El-Din
+1 @ Jean-Louis

On Mon, Nov 15, 2010 at 9:29 AM, Jean-Louis MONTEIRO
<[hidden email]> 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