Speeding up integration tests

[marc.esher]

Greetings all,

I've got a project that uses the Spring Security, Spring Security UI, and BlazeDS Plugins. When I run integration tests, I spend over a minute just waiting for these plugins to "boot", as it were, before my tests even get run.

Is there any way, during integration tests, to either speed up, or remove entirely, the loading of these plugins? I know it's a silly sounding request... after all, I'm integration testing. But I'm not integration testing any of the spring security or Blaze stuff, so I'd prefer it simply not be there so that it doesn't take a single test over a minute to run.

At this point, I'm not interested in Mocking b/c I really do want to test all the real bits.

Any advice is most appreciated.

[Dean Del Ponte-2]

Spring security can be disabled for specific environments within Config.groovy.

Just add:

grails.plugins.springsecurity.active = false

To your test environment.

- Dean Del Ponte 

On Mon, Jun 11, 2012 at 8:35 AM, marc.esher <[hidden email]> wrote:

Greetings all,

I've got a project that uses the Spring Security, Spring Security UI, and
BlazeDS Plugins. When I run integration tests, I spend over a minute just
waiting for these plugins to "boot", as it were, before my tests even get
run.

Is there any way, during integration tests, to either speed up, or remove
entirely, the loading of these plugins? I know it's a silly sounding
request... after all, I'm integration testing. But I'm not integration
testing any of the spring security or Blaze stuff, so I'd prefer it simply
not be there so that it doesn't take a single test over a minute to run.

At this point, I'm not interested in Mocking b/c I really do want to test
all the real bits.

Any advice is most appreciated.

--
View this message in context: http://grails.1312388.n4.nabble.com/Speeding-up-integration-tests-tp4629900.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[marc.esher]

Dean, thanks for the reply. I had tried that, but I get this error from the BlazeDS plugin:

| Error Error running script test-app integration:: org.springframework.beans.factory.BeanCreationException: Error creating bean with name '_messageBroker': Cannot resolve reference to bean 'blazeDsMessageBrokerLoginCommand' while setting bean property 'configProcessors' with key [0]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'blazeDsMessageBrokerLoginCommand': Cannot resolve reference to bean 'authenticationManager' while setting constructor argument; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'authenticationManager' is defined (Use --stacktrace to see the full trace)

Unfortunately, it doesn't look like the Blaze plugin can be disabled, and I'm not quite sure how I'd mock the disabled bits from Spring Security in order to get Blaze to stop complaining. I'd really like to have Blaze disable-able as well, and I imagine I could figure out how to do it, but the problem I'm having with grails plugins in general is that since they are "external", they seem to be harder to deal with when you make changes to them (any advice there is also most welcome).

I guess my next step will be trying to figure out how to mock that stuff during a test run.

[marc.esher]

huh, that was easy enough. Just created a mock Authenticationmanager with a null-returning authenticate, then defined it in resources.groovy.

MockAuthenticationManager.groovy:

class MockAuthenticationManager implements AuthenticationManager {
    Authentication authenticate(Authentication authentication) {
        return null  
    }
}

resources.groovy:

if (GrailsUtil.environment == "test"){
            authenticationManager(MockAuthenticationManager){}
    }

[burtbeckwith]

So, is it faster?

Burt

marc.esher wrote

huh, that was easy enough. Just created a mock Authenticationmanager with a null-returning authenticate, then defined it in resources.groovy.

MockAuthenticationManager.groovy:

class MockAuthenticationManager implements AuthenticationManager {
    Authentication authenticate(Authentication authentication) {
        return null  
    }
}

resources.groovy:

if (GrailsUtil.environment == "test"){
            authenticationManager(MockAuthenticationManager){}
    }

[marc.esher]

Burt,

It's faster by perhaps tens of seconds sometimes, and no faster others. My integration test times are all over the map, in explicably (no amount of digging has shown me why they sometimes take 90 seconds and sometimes 20... which irritates me to no end b/c typically in my experience it's fairly easy to pinpoint a culprit).  I blame all the corporate security junk installed on this thing.

Sometimes it's the tests themselves that run long, and sometimes it's the spinning up of the grails environment.

Thanks for asking.