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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
