Grails 2.0 - old style tests or new style tests

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Grails 2.0 - old style tests or new style tests

Roshan Dawrani
Hi,

I have a basic question, and hope it's not a silly one. 

Does Grails 2.0 treat old style tests (extends UnitSpec / ControllerSpec) different from new style tests that use @TestFor / @Mock?

For example, the new GORM behavior (which depends on grails-data-mapping project) for mocked domain classes - does that kick in only if @TestFor / @Mock are used and not if tests continue to extend UnitSpec / ControllerSpec (and get their mock behavior through MockUtils, say)?

If it is correct, I would like to know if that is a short-term arrangement or it's on purpose to support projects that do not want to move to the new grails-data-mapping based GORM stores.
Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.0 - old style tests or new style tests

ld@ldaley.com

On 20/12/2011, at 8:11 AM, Roshan Dawrani wrote:

Hi,

I have a basic question, and hope it's not a silly one. 

Does Grails 2.0 treat old style tests (extends UnitSpec / ControllerSpec) different from new style tests that use @TestFor / @Mock?

For example, the new GORM behavior (which depends on grails-data-mapping project) for mocked domain classes - does that kick in only if @TestFor / @Mock are used and not if tests continue to extend UnitSpec / ControllerSpec (and get their mock behavior through MockUtils, say)?

The old classes are targeted to be deprecated. Once there is some confidence that the majority of cases they covered are covered with the new mechanism, they will be deprecated and then removed.

If it is correct, I would like to know if that is a short-term arrangement or it's on purpose to support projects that do not want to move to the new grails-data-mapping based GORM stores.

I am unsure why ever class is decorated (sorting that out), but Graeme has been clear that the old stuff is now to be considered deprecated and all new code should be written with the new mechanism.
Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.0 - old style tests or new style tests

Roshan Dawrani
Thanks for the clarifying the official stand on the situation, Luke.

It does indeed make sense to have that kind of behavior differences only as a short term arrangement.

On Tue, Dec 20, 2011 at 4:57 PM, [hidden email] <[hidden email]> wrote:

On 20/12/2011, at 8:11 AM, Roshan Dawrani wrote:

Hi,

I have a basic question, and hope it's not a silly one. 

Does Grails 2.0 treat old style tests (extends UnitSpec / ControllerSpec) different from new style tests that use @TestFor / @Mock?

For example, the new GORM behavior (which depends on grails-data-mapping project) for mocked domain classes - does that kick in only if @TestFor / @Mock are used and not if tests continue to extend UnitSpec / ControllerSpec (and get their mock behavior through MockUtils, say)?

The old classes are targeted to be deprecated. Once there is some confidence that the majority of cases they covered are covered with the new mechanism, they will be deprecated and then removed.

If it is correct, I would like to know if that is a short-term arrangement or it's on purpose to support projects that do not want to move to the new grails-data-mapping based GORM stores.

I am unsure why ever class is decorated (sorting that out), but Graeme has been clear that the old stuff is now to be considered deprecated and all new code should be written with the new mechanism.



--
Roshan