Grails
  1. Grails
  2. GRAILS-7506

mockDomain() doesn't create isDirty() and related methods

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.7, 2.0 final, 2.0.4
    • Fix Version/s: 2.3-RC1
    • Component/s: Testing
    • Labels:
    • Testcase included:
      yes

      Description

      mockDomain() doesn't mock dirty checking related methods in domain classes. These include:

      isDirty()
      getPersistentValue()
      getDirtyPropertyNames()

      Workaround is to test anything that requires these in an integration test, but this is sub-optimal IMHO.

        Activity

        Hide
        Robert Fletcher added a comment -

        This is still a problem in Grails 2 when using @Mock or @TestFor

        Show
        Robert Fletcher added a comment - This is still a problem in Grails 2 when using @Mock or @TestFor
        Hide
        Peter Locke added a comment -

        A workaround is to dynamically add the method yourself in your unit tests

        YourDomain.metaClass.isDirty =

        { //do functionality here }
        Show
        Peter Locke added a comment - A workaround is to dynamically add the method yourself in your unit tests YourDomain.metaClass.isDirty = { //do functionality here }
        Hide
        Raviteja added a comment -

        Attached a testcase, any chance of getting this fixed?

        Show
        Raviteja added a comment - Attached a testcase, any chance of getting this fixed?
        Hide
        Graeme Rocher added a comment -

        it is non-trivial to implement dirty check tracking in a unit test. We could add methods that simply return false in the short term, but a broader implementation is more complex. In the meantime is is not that complicated to use the mocking API to mock the methods.

        Show
        Graeme Rocher added a comment - it is non-trivial to implement dirty check tracking in a unit test. We could add methods that simply return false in the short term, but a broader implementation is more complex. In the meantime is is not that complicated to use the mocking API to mock the methods.
        Hide
        Raviteja added a comment -

        Yes. I'm mocking them currently not a blocker as of now.

        Show
        Raviteja added a comment - Yes. I'm mocking them currently not a blocker as of now.
        Hide
        Dominique Jocal added a comment -

        Graeme, Ravi,

        i agree mocking is the right path.
        however, to achieve it on plain domain instances saved and retrieved by the test implementations of save() and findBy(), i feel like i must do partial mocking : overwriting the method through the metaclass.

        it's not that elegant in the test code; we especially have to restore the former method at the end...

        what do you think of offering a "setDirty" (i let you find the correct name) in the test implementation of domain classes mixins, such as for save() and findBy() ?

        thank you for your opinion

        Show
        Dominique Jocal added a comment - Graeme, Ravi, i agree mocking is the right path. however, to achieve it on plain domain instances saved and retrieved by the test implementations of save() and findBy(), i feel like i must do partial mocking : overwriting the method through the metaclass. it's not that elegant in the test code; we especially have to restore the former method at the end... what do you think of offering a "setDirty" (i let you find the correct name) in the test implementation of domain classes mixins, such as for save() and findBy() ? thank you for your opinion

          People

          • Assignee:
            Graeme Rocher
            Reporter:
            Gustavo Giráldez
          • Votes:
            9 Vote for this issue
            Watchers:
            13 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Last Reviewed:

              Development