Grails

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

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.3.7, 2.0 final, 2.0.4
  • Fix Version/s: None
  • 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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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:
    Unassigned
    Reporter:
    Gustavo Giráldez
Vote (9)
Watch (12)

Dates

  • Created:
    Updated:
    Last Reviewed: