Details

    • Type: Sub-task Sub-task
    • Status: Resolved Resolved
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 2.5.1.RELEASE
    • Component/s: GRAILS
    • Labels:
      None
    1. _StsGrailsTest.groovy
      15 kB
      Kris De Volder (c)
    2. StsTestApp.groovy
      4 kB
      Kris De Volder (c)

      Activity

      Hide
      Christian Dupuis added a comment -

      Graeme, I'm not sure that we need for that.

      With the current set of tools I can just do right-click run as JUnit and you get a green bar. This does run Grails tests. Is that it?

      Christian

      Show
      Christian Dupuis added a comment - Graeme, I'm not sure that we need for that. With the current set of tools I can just do right-click run as JUnit and you get a green bar. This does run Grails tests. Is that it? Christian
      Hide
      Graeme Rocher added a comment -

      Hi Christian,

      Running unit tests doesn't require anything new no, but running integration tests does. You need to call

      grails test-app --integration [TEST NAME]
      

      Grails will handle booting an in memory db etc. Also to get the green/red bar thing going in the UI you need to install your own test running by passing "grails.test.runner"

      grails -Dgrails.test.runner=com.springsource.sts.GrailsSTSTestRunner test-app --integration [TEST NAME]
      

      GrailsSTSTestRunner has to subclass org.codehaus.groovy.grails.test.DefaultGrailsTestRunner in order to get test events back and of course you have to amend the classpath when calling Grails to get it to work

      Show
      Graeme Rocher added a comment - Hi Christian, Running unit tests doesn't require anything new no, but running integration tests does. You need to call grails test-app --integration [TEST NAME] Grails will handle booting an in memory db etc. Also to get the green/red bar thing going in the UI you need to install your own test running by passing "grails.test.runner" grails -Dgrails.test.runner=com.springsource.sts.GrailsSTSTestRunner test-app --integration [TEST NAME] GrailsSTSTestRunner has to subclass org.codehaus.groovy.grails.test.DefaultGrailsTestRunner in order to get test events back and of course you have to amend the classpath when calling Grails to get it to work
      Hide
      Ryan Crumley added a comment -

      To me it is very important to be able to quickly launch and relaunch a test without leaving Eclipse. This works extremely well in traditional java projects and I would think many java developers would see this as a barrier to adopting grails. Obviously being able to debug test cases via this route is very important.

      Show
      Ryan Crumley added a comment - To me it is very important to be able to quickly launch and relaunch a test without leaving Eclipse. This works extremely well in traditional java projects and I would think many java developers would see this as a barrier to adopting grails. Obviously being able to debug test cases via this route is very important.
      Hide
      Andrew Eisenberg (c) added a comment -

      I'll have a look at this issue this coming week.

      Honestly, I don't know how difficult this will be. Currently, grails tooling in STS just delegates grails commands to an external process. Creating a launcher for this command would require running Grails as an internal process and collecting feedback from the running JUnit tests.

      First, I'll get a feel for how difficult this is going to be. Then I'll start trying to implement.

      Show
      Andrew Eisenberg (c) added a comment - I'll have a look at this issue this coming week. Honestly, I don't know how difficult this will be. Currently, grails tooling in STS just delegates grails commands to an external process. Creating a launcher for this command would require running Grails as an internal process and collecting feedback from the running JUnit tests. First, I'll get a feel for how difficult this is going to be. Then I'll start trying to implement.
      Hide
      Luke Daley added a comment -

      There have been some recent changes that change the way that you will need to implement this.

      First of all, we have introduced a generic mechanism to insert a listener to build events. See http://github.com/grails/grails/blob/20f0273adafab94f695c7c3b2ce84f3a11fe6a4f/grails/src/java/grails/build/GrailsBuildListener.java

      You can insert a listener when launching grails by specifying the name of a class that implements this interface...

      grails -Dgrails.build.listeners=org.MyListener1,org.MyListener2 «command»
      

      See http://grails.org/doc/latest/guide/4.%20The%20Command%20Line.html#4.3%20Hooking%20into%20Events for more on the events raised by the Grails build system.

      The second part to the puzzle is the addition of new events for testing. See http://github.com/alkemist/grails/blob/e6c55b6c12c3fbeb7bfce66a946f5f6439dde5ed/grails/src/java/org/codehaus/groovy/grails/test/event/GrailsTestEventPublisher.groovy

      This will be in Grails 1.2

      Show
      Luke Daley added a comment - There have been some recent changes that change the way that you will need to implement this. First of all, we have introduced a generic mechanism to insert a listener to build events. See http://github.com/grails/grails/blob/20f0273adafab94f695c7c3b2ce84f3a11fe6a4f/grails/src/java/grails/build/GrailsBuildListener.java You can insert a listener when launching grails by specifying the name of a class that implements this interface... grails -Dgrails.build.listeners=org.MyListener1,org.MyListener2 «command» See http://grails.org/doc/latest/guide/4.%20The%20Command%20Line.html#4.3%20Hooking%20into%20Events for more on the events raised by the Grails build system. The second part to the puzzle is the addition of new events for testing. See http://github.com/alkemist/grails/blob/e6c55b6c12c3fbeb7bfce66a946f5f6439dde5ed/grails/src/java/org/codehaus/groovy/grails/test/event/GrailsTestEventPublisher.groovy This will be in Grails 1.2
      Hide
      Andrew Eisenberg (c) added a comment - - edited

      Luke,

      Thanks for the lead. There are two general directions I can go about to implement this:

      1. JDT's JUnit integration launches the integration tests. This way would be nice because launching from JDT would immediately ensure that all the test listeners are set up properly so that the JUnit view correctly shows the green and red bars.
      2. Launch as a grails application and plug the listeners in the way described above. This way, of course, ensures that grails is happy, but it is a pain to then ensure that JDT is happy.

      The second option also depends on more functionality that is not yet implemented: the capability to run grails commands in-process, rather than as an external tool. I'll create a sub-task for that.

      Show
      Andrew Eisenberg (c) added a comment - - edited Luke, Thanks for the lead. There are two general directions I can go about to implement this: JDT's JUnit integration launches the integration tests. This way would be nice because launching from JDT would immediately ensure that all the test listeners are set up properly so that the JUnit view correctly shows the green and red bars. Launch as a grails application and plug the listeners in the way described above. This way, of course, ensures that grails is happy, but it is a pain to then ensure that JDT is happy. The second option also depends on more functionality that is not yet implemented: the capability to run grails commands in-process, rather than as an external tool. I'll create a sub-task for that.
      Hide
      Andrew Eisenberg (c) added a comment -

      Interesting...I see now that when I do Debug As -> Grails Command (run-app), I can get debugging to work, but when I Debug As -> Grails Command... , breakpoints are not stopped at.

      Also, interesting that the Grails launch configurations are not being saved. I'll have to look at that, too.

      Show
      Andrew Eisenberg (c) added a comment - Interesting...I see now that when I do Debug As -> Grails Command (run-app), I can get debugging to work, but when I Debug As -> Grails Command... , breakpoints are not stopped at. Also, interesting that the Grails launch configurations are not being saved. I'll have to look at that, too.
      Hide
      Kim Betti added a comment -

      Nice! I've really been missing this!

      Please make sure that there is an easy way of running tests related to the current class you're working on.
      "Test this class" or something similar.

      Show
      Kim Betti added a comment - Nice! I've really been missing this! Please make sure that there is an easy way of running tests related to the current class you're working on. "Test this class" or something similar.
      Hide
      Kris De Volder (c) added a comment -

      I will be looking at some of this, so reassigned this task to me.

      As a first attempt at some integration, I'll try to arrange for a "Run As test-app" menu item that can launch the test-app command. When the command finished will automatically open the test result file in the JUnit viewer.

      This shouldn't be hard to implement. After that I will probably have a look at tighter integration.

      Show
      Kris De Volder (c) added a comment - I will be looking at some of this, so reassigned this task to me. As a first attempt at some integration, I'll try to arrange for a "Run As test-app" menu item that can launch the test-app command. When the command finished will automatically open the test result file in the JUnit viewer. This shouldn't be hard to implement. After that I will probably have a look at tighter integration.
      Hide
      Kris De Volder (c) added a comment -

      I've committed something that adds a "Run As >> Grails Command (test-app)" similar to existing
      "Run As >> Grails Command (run-app)"

      It waits for the command to complete and then opens up the test results automatically with the JUnit viewer.

      This is not quite the level of integration that we ultimately want, but it was easy to implement in a short time...

      Will keep the issue open, since I think we do want better integration somehow.

      Show
      Kris De Volder (c) added a comment - I've committed something that adds a "Run As >> Grails Command (test-app)" similar to existing "Run As >> Grails Command (run-app)" It waits for the command to complete and then opens up the test results automatically with the JUnit viewer. This is not quite the level of integration that we ultimately want, but it was easy to implement in a short time... Will keep the issue open, since I think we do want better integration somehow.
      Hide
      Kris De Volder (c) added a comment -

      Graeme, I hope you are still watching this issue, I need some help

      We can now do "Run As >> Grails Command (test-app)" on the following three selections in Eclipse

      • Grails project => runs "grails test-app" command
      • Grails test/unit folder => runs "grails test-app -unit" command
      • Grails test/integration folder => runs "grails test-app -integration" command

      This should be in the next milestone release that's coming out any day now.

      The test results get opened after the command finishes. This is really just a quick hack and I see the following problems with it:

      1) We don't see the "progress" in the viewer while the tests are running.
      2) We can't relaunch (a specific) test(s) by clicking on them in the viewer.
      3) We are loosing the System.out and System.err output produced by the tests (I think grails captures it and stores in some of the files produced by the test run, but they don't show in the Console view and the JDT viewer doesn't provide any GUI to view them).

      I think that 1) and 2) are really things that user's want and should be in a reasonable implementation of testing support for Grails/Eclipse.

      I believe that it would be feasible to get 1) addressed by using the BuildListener mechanism.

      But how do we allow the user to re-run specific tests by selecting them from the UI? I.e. is there a way to tell Grails to run a specific test.

      I was looking at

      http://www.grails.org/doc/latest/ref/Command%20Line/test-app.html

      but it looks like there's no way to tell Grails to run a specific test-method in a specific class.

      I also tried to look for "DefaultGrailsTestRunner" mentioned above as a possible way into this... but it seems that class no longer exists.

      Any hints or pointers in the right direction much appreciated.

      Thanks

      Kris

      Show
      Kris De Volder (c) added a comment - Graeme, I hope you are still watching this issue, I need some help We can now do "Run As >> Grails Command (test-app)" on the following three selections in Eclipse Grails project => runs "grails test-app" command Grails test/unit folder => runs "grails test-app -unit" command Grails test/integration folder => runs "grails test-app -integration" command This should be in the next milestone release that's coming out any day now. The test results get opened after the command finishes. This is really just a quick hack and I see the following problems with it: 1) We don't see the "progress" in the viewer while the tests are running. 2) We can't relaunch (a specific) test(s) by clicking on them in the viewer. 3) We are loosing the System.out and System.err output produced by the tests (I think grails captures it and stores in some of the files produced by the test run, but they don't show in the Console view and the JDT viewer doesn't provide any GUI to view them). I think that 1) and 2) are really things that user's want and should be in a reasonable implementation of testing support for Grails/Eclipse. I believe that it would be feasible to get 1) addressed by using the BuildListener mechanism. But how do we allow the user to re-run specific tests by selecting them from the UI? I.e. is there a way to tell Grails to run a specific test. I was looking at http://www.grails.org/doc/latest/ref/Command%20Line/test-app.html but it looks like there's no way to tell Grails to run a specific test-method in a specific class. I also tried to look for "DefaultGrailsTestRunner" mentioned above as a possible way into this... but it seems that class no longer exists. Any hints or pointers in the right direction much appreciated. Thanks Kris
      Hide
      Kris De Volder (c) added a comment -

      Allright... I found that it is possible to run individual test methods.

      See class "org.codehaus.groovy.grails.test.GrailsTestTargetPattern" in the Grails 1.3.4 source code.

      The test-app command supports a kind of pattern language to determine which tests to run and it recognizes patterns of the form (example)

      gTunes.Song.testValidation

      as method patterns. The key is that the last piece of the pattern (pieces separated by "." must start with a lowercase letter.

      Another tidbit of info needed to know here is that the words "Test" or "Tests" has to be stripped from the end of the Test class name or the pattern will not match.

      The example above identifies the testValidation method inside a class

      gTunes.SongTests or gTunes.SongTest

      Show
      Kris De Volder (c) added a comment - Allright... I found that it is possible to run individual test methods. See class "org.codehaus.groovy.grails.test.GrailsTestTargetPattern" in the Grails 1.3.4 source code. The test-app command supports a kind of pattern language to determine which tests to run and it recognizes patterns of the form (example) gTunes.Song.testValidation as method patterns. The key is that the last piece of the pattern (pieces separated by "." must start with a lowercase letter. Another tidbit of info needed to know here is that the words "Test" or "Tests" has to be stripped from the end of the Test class name or the pattern will not match. The example above identifies the testValidation method inside a class gTunes.SongTests or gTunes.SongTest
      Hide
      Kris De Volder (c) added a comment -

      I've added support for "Run As >> Grails (test-app)" when selecting an individual resource. It supports two different uses:

      • Select a "XXXTest(s).groovy" file. The tests in that file are executed.
      • Select another source file. E.g. "Song.groovy" from domain folder.
        The tests associated with the Song class are executed.
      Show
      Kris De Volder (c) added a comment - I've added support for "Run As >> Grails (test-app)" when selecting an individual resource. It supports two different uses: Select a "XXXTest(s).groovy" file. The tests in that file are executed. Select another source file. E.g. "Song.groovy" from domain folder. The tests associated with the Song class are executed.
      Hide
      Graeme Rocher added a comment -

      Hi Kris,

      Sorry for the late reply. This is a good step, but the big thing is the lack of feedback via the UI, so I don't think this issue can be regarded as properly addressed.

      In order to get the feedback in the UI you will need to register a build listener. See this project for an example of how to do so:

      http://github.com/alkemist/grails-build-listening

      Show
      Graeme Rocher added a comment - Hi Kris, Sorry for the late reply. This is a good step, but the big thing is the lack of feedback via the UI, so I don't think this issue can be regarded as properly addressed. In order to get the feedback in the UI you will need to register a build listener. See this project for an example of how to do so: http://github.com/alkemist/grails-build-listening
      Hide
      Kris De Volder (c) added a comment -

      Hi Graeme,

      The last few days I've been hacking away at getting something up and running that fits into the Eclipse JUnit UI. Unfortunately, the events that are being reported by GrailsBuildListener are not sufficient. The UI needs to get a copy of the test-tree before the tests start executing (so the test view can be populated).

      I have hacked-up something that modifies the TestApp and _GrailsTest scripts in Grails 1.3.4 to be able to get these events.

      The good news is... I was able to get something going that "sort of works". The bad news is that I'm not sure if it doesn't in some way break the test running scripts. I haven't got good projects with realistic test suites to try it out on. I've had to make some changes to the ordering in which things get prepared and executed (which is a bit scary with all the state mutations and implicit context dependencies in the Gant scripts).

      I'll attach the modified scripts here, maybe someone on the Grails team can have a look at them and give me some feedback.

      Kris

      PS: I also had some issues with classpath and classloaders to get the BuildListener implementation I made loaded up AND able to access the classes it needs (like Suite class from JUnit4) without classloader constraint violations.

      Show
      Kris De Volder (c) added a comment - Hi Graeme, The last few days I've been hacking away at getting something up and running that fits into the Eclipse JUnit UI. Unfortunately, the events that are being reported by GrailsBuildListener are not sufficient. The UI needs to get a copy of the test-tree before the tests start executing (so the test view can be populated). I have hacked-up something that modifies the TestApp and _GrailsTest scripts in Grails 1.3.4 to be able to get these events. The good news is... I was able to get something going that "sort of works". The bad news is that I'm not sure if it doesn't in some way break the test running scripts. I haven't got good projects with realistic test suites to try it out on. I've had to make some changes to the ordering in which things get prepared and executed (which is a bit scary with all the state mutations and implicit context dependencies in the Gant scripts). I'll attach the modified scripts here, maybe someone on the Grails team can have a look at them and give me some feedback. Kris PS: I also had some issues with classpath and classloaders to get the BuildListener implementation I made loaded up AND able to access the classes it needs (like Suite class from JUnit4) without classloader constraint violations.
      Hide
      Kris De Volder (c) added a comment - - edited

      These are the changed (and renamed) scripts.

      The main goal for these changes is to send events with references to all the JUnit 4 Suite instances before any tests get executed.

      Show
      Kris De Volder (c) added a comment - - edited These are the changed (and renamed) scripts. The main goal for these changes is to send events with references to all the JUnit 4 Suite instances before any tests get executed.
      Hide
      Kris De Volder (c) added a comment -

      Waiting for this related grails issue to be resolved to make progress on this.
      http://jira.codehaus.org/browse/GRAILS-6755

      Show
      Kris De Volder (c) added a comment - Waiting for this related grails issue to be resolved to make progress on this. http://jira.codehaus.org/browse/GRAILS-6755
      Hide
      Kris De Volder (c) added a comment -

      I'm resolving this issue. There is certainly more work that can be done to improve Grails/STS JUnit integration. However, it is now already possible to run integration tests from within STS.

      Leaving the issue open gives the impression that this isn't possible and no progress has been made on this issue.

      I'll create a new issue to track work on improving integration between STS and Grails.

      Show
      Kris De Volder (c) added a comment - I'm resolving this issue. There is certainly more work that can be done to improve Grails/STS JUnit integration. However, it is now already possible to run integration tests from within STS. Leaving the issue open gives the impression that this isn't possible and no progress has been made on this issue. I'll create a new issue to track work on improving integration between STS and Grails.
      Hide
      Kris De Volder (c) added a comment -
      Show
      Kris De Volder (c) added a comment - New issue created https://issuetracker.springsource.com/browse/STS-1555

        People

        • Assignee:
          Kris De Volder (c)
          Reporter:
          Graeme Rocher
        • Votes:
          14 Vote for this issue
          Watchers:
          9 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:
            First Response Date: