Grails

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

Details

  • Type: Improvement Improvement
  • Status: Closed 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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (9)
Watch (10)

Dates

  • Created:
    Updated:
    Resolved:
    Last Reviewed: