|
Our project is fairly large (about 350 domain classes) so the startup time for grails is very long, upwards of about 2 minutes. The same is true for running just a single integration test which is very painful when you are trying to do something like TDD.
I was thinking what we need is a spork-ish plugin for grails. Basically, what I want to do is allow the server to startup in "test" mode and then tell it to run integration tests on the running instance, thereby saving all the bootstrap time. Obviously, the test classes will need to be reloadable in the running instance similar to controllers, services, etc. I start playing around with it but there are definitely some challenges with class loading, etc. I think the test-server will become "dirty" after awhile and might need restarting, but it still could be a significant boost to our performance.
So basically, I'm thinking the parts would be: 1. Script to start the server in "test" mode, including the test-classes in the EmbeddableServer classloader (I have this, I think)
2. A controller that can essentially do alot of what _GrailsTest is doing now (create JUnit4GrailsTestType impls, run them, etc.) 3. Script to take the test to run, send it to the controller and display results.
For anyone that has used spork or spec_server (or guard) for Rails, this is what I'm shooting for. So..... Is this even possible or will there be insurmountable problems with classloading and other things I can't even think of? I'm willing to invest some time trying to proof it out unless Graeme or someone just says forget about it.
Rgds, Aaron
|
|
See http://grails.org/plugin/functional-test-development. I believe this is what you're looking for. It needs some minor updates to work with grails 2 correctly:
https://github.com/alkemist/grails-functional-test-development/issues/4. I know this is functional testing and you're looking for integration testing, but maybe this can give you some pointers on where to start to develop a plugin like this for integration tests or to improve it.
-Brian On Thu, Jun 7, 2012 at 5:18 PM, Aaron Long <[hidden email]> wrote: Our project is fairly large (about 350 domain classes) so the startup time for grails is very long, upwards of about 2 minutes. The same is true for running just a single integration test which is very painful when you are trying to do something like TDD. |
|
It's the same idea, but I think the implementation would be a lot different for integration vs. functional testing. The functional tests are already designed to run in a remote mode (using the baseUrl argument) so I think this plugin just takes advantage of that.
The plugin does reference the Groovy Remote stuff which might be something that could be used for this problem. My biggest problem right now is that I want to reuse the JUnit4GrailsTestType to wrap and run the tests, but it requires a buildBinding which I can't seem to find or create inside a running server. I may be able to mock it out to provide what's needed for the test methods to work....still digging around.
Thanks for the heads up on the other plugins. -Aaron On Thu, Jun 7, 2012 at 9:04 PM, Brian Saville <[hidden email]> wrote: See http://grails.org/plugin/functional-test-development. I believe this is what you're looking for. It needs some minor updates to work with grails 2 correctly: https://github.com/alkemist/grails-functional-test-development/issues/4. I know this is functional testing and you're looking for integration testing, but maybe this can give you some pointers on where to start to develop a plugin like this for integration tests or to improve it. |
|
In reply to this post by longwa
> So basically, I'm thinking the parts would be:
> > 1. Script to start the server in "test" mode, including the test-classes in > the EmbeddableServer classloader (I have this, I think) > 2. A controller that can essentially do alot of what _GrailsTest is doing > now (create JUnit4GrailsTestType impls, run them, etc.) > 3. Script to take the test to run, send it to the controller and display > results. I'm not sure this is the right approach. At least I don't think it's the easiest. I would instead look at the existing integration test code and instead of tearing down the application instance at the end of the tests, go into a loop where users can enter a test command to re-run them, or quit to exit the loop (and end the tests). Peter -- Peter Ledbrook Grails Advocate SpringSource - A Division of VMware --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
Peter,
Yeah, definitely not the easiest. The reason I didn't like the loop approach was that I was hoping to be able to continue using the IntelliJ test runner stuff to drive the testing. The closer the workflow was to normal "grails test-app", the better it would integrate. I'm thinking initially, I may just go with something like rails guard where the tests just run automatically if the test file is updated.
I have a working service right now that will load the test classes on demand, execute them in the normal grails test context (using a custom JUnit4GrailsTestType class), collect the results and display them or output them to the console. When I update the test .class files, the updated tests are loaded and run properly.
Right now, my challenge is getting the server to recompile the test classes when they change. My solution was to create a custom script which essentially is a copy or RunApp, but with code from _GrailsTest to scan and recompile the test files when they change and then notify the server to run the test. One problem is that the startGrails script is hard coded to only enable class reloading for "run-app". So if I start my server with my own custom script, I don't get any reloading. I guess I could always start the server with a normal run-app and then just have another script that loops and recompiles test classes as they change (or as requested via a prompt, like you mentioned).
-Aaron # Enable agent-based reloading for the 'run-app' command. if ! $DISABLE_RELOADING; then for a in "$@"; do if [ "$a" = "run-app" ]; then
AGENT=$AGENT_STRING fi done if [ $# = 0 ]; then AGENT=$AGENT_STRING fi fi On Mon, Jun 11, 2012 at 5:16 AM, Peter Ledbrook <[hidden email]> wrote:
|
| Powered by Nabble | Edit this page |
