Grails
  1. Grails
  2. GRAILS-8555

provide ability to specify certain cross-cutting concerns typically specified in config.groovy during unit tests

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0 final
    • Fix Version/s: 2.1.5, 2.2.2, 2.3-M1
    • Component/s: Configuration
    • Labels:
      None

      Description

      there are two scenarios i'm thinking of:

      (1) grails.gorm.failOnError = true

      can't really simulate this in unit test, so basically requires consistent (and redundant) <domain instance>.save(failOnError: true) to make unit tests consistent with app at runtime, which eliminates the benefit of that setting.

      see this thread for reference: http://grails.1312388.n4.nabble.com/unit-testing-grails-gorm-failOnError-true-td4231435.html

      (2) logging

      sometimes unit tests fail and sometimes log output can be a huge benefit in tracking down the issue.

      the now defunct 'mockLogging(class, enableDebug=true)' attempted to address this, but is no longer in play in 2.x+

      see this thread for reference: http://grails.1312388.n4.nabble.com/grails-2-0-0-RC1-mockLogging-td3993095.html

      ------------

      on one level w.r.t. the 'dry' principal it would be cool to have unit tests 'honor' config.groovy, but i'm sure it's not that simple, so i'll leave solutioning to the experts

        Activity

        Hide
        Graeme Rocher added a comment -

        Logging should now appear in standard out of unit test reports for Grails 2.0.1

        Show
        Graeme Rocher added a comment - Logging should now appear in standard out of unit test reports for Grails 2.0.1
        Hide
        Esteban Invernizzi added a comment -

        (1) is working for me when saving new instances of Domain classes, but not on update

        Show
        Esteban Invernizzi added a comment - (1) is working for me when saving new instances of Domain classes, but not on update
        Hide
        John Fletcher added a comment -

        Before attempting to implement the failOnError improvement, let's define the desired behaviour. Can we just read the config and enforce that? Peter Ledbrook said (before the 2.0 testing framework was introduced) "A mock framework should allow for fine-grained control, so this is something I think should be switched on and off in GrailsUnitTestCase or via the mockDomain() method. However, the newer mocking framework for GORM that I mentioned previously may be the future, so I'm not sure we should add this now." (http://grails.1312388.n4.nabble.com/Unit-testing-with-failOnError-true-td2718543.html).

        So does this mean we should aim to enforce the setting from Config.groovy by default, but allow it to be overridden per-save or per-test? I would argue that per-save overriding is already there - just specify saveOnError in your save arguments and you will override the default. So the only thing that we might want to implement is a per-test or per-test-class override. Per test-class override probably doesn't make sense. So do we want to default to the Config.groovy setting with the possibility of per-test override?

        Show
        John Fletcher added a comment - Before attempting to implement the failOnError improvement, let's define the desired behaviour. Can we just read the config and enforce that? Peter Ledbrook said (before the 2.0 testing framework was introduced) "A mock framework should allow for fine-grained control, so this is something I think should be switched on and off in GrailsUnitTestCase or via the mockDomain() method. However, the newer mocking framework for GORM that I mentioned previously may be the future, so I'm not sure we should add this now." ( http://grails.1312388.n4.nabble.com/Unit-testing-with-failOnError-true-td2718543.html ). So does this mean we should aim to enforce the setting from Config.groovy by default, but allow it to be overridden per-save or per-test? I would argue that per-save overriding is already there - just specify saveOnError in your save arguments and you will override the default. So the only thing that we might want to implement is a per-test or per-test-class override. Per test-class override probably doesn't make sense. So do we want to default to the Config.groovy setting with the possibility of per-test override?
        Hide
        John Towell added a comment -

        How is this possibly still open? What are people doing to work-around this issue? We have standardized on the grails.gorm.failOnError=true setting, meaning our save methods look just like .save(). Does the unit test framework not support this approach?

        Show
        John Towell added a comment - How is this possibly still open? What are people doing to work-around this issue? We have standardized on the grails.gorm.failOnError=true setting, meaning our save methods look just like .save(). Does the unit test framework not support this approach?
        Hide
        Graeme Rocher added a comment -

        @John - patches / pull requests welcome welcome

        As a workaround to this issue you can do:

        MyClass.currentGormInstanceApi().failOnError = true
        

        In a setUp method of the unit test. We'll look at providing a proper solution in the next release

        Show
        Graeme Rocher added a comment - @John - patches / pull requests welcome welcome As a workaround to this issue you can do: MyClass.currentGormInstanceApi().failOnError = true In a setUp method of the unit test. We'll look at providing a proper solution in the next release
        Hide
        Peter N. Steinmetz added a comment -

        I have raised a separate issue regarding the lack of log output to console during testing - GRAILS-9812. Log output as configured in Config.groovy is reflected in the test reports, but cannot be made to appear in the console.

        Show
        Peter N. Steinmetz added a comment - I have raised a separate issue regarding the lack of log output to console during testing - GRAILS-9812 . Log output as configured in Config.groovy is reflected in the test reports, but cannot be made to appear in the console.

          People

          • Assignee:
            Graeme Rocher
            Reporter:
            tony kerz
          • Votes:
            9 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Last Reviewed:

              Development