RFC: more test-app changes.

[Luke Daley]

http://github.com/alkemist/grails/commit/fa6bcc1dcda4cf02d61f4269604303950f1a81e6

Disclaimer: this is not the intended final state, the way this wraps  
the previous API is somewhat crude.

Each test type is expected to add a closure variable to the binding  
named “«type»TestsPreparation”. It _must_ return something that  
supports the interface of GrailsTestTypeRunner. This should allow  
completely different test runners to be plugged in easily.

If new test types are JUnit 3 test types, they don't have to do  
anything.

This _is_  potentially breaking for testing plugins that add new test  
types but the fix is trivial. This also means that in some cases  
testing plugins will have to handle pre 1.2 specially, but again this  
will not be difficult.

Please let me know what you think.



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-3]

Looks like a good improvement, but the removal of this code:

- String testRunnerClassName =
System.getProperty("grails.test.runner") ?:
"org.codehaus.groovy.grails.test.DefaultGrailsTestRunner"

Breaks the ability for an IDE to specify an alternative test runner on
the command line so that progress reports

Also as I said previously I am concerned about how we are going to
handle upgrades. Do you plan to have patches in place for all the
different testing plugins in time for RC1?

Regards,

On Thu, Oct 29, 2009 at 12:51 PM, Luke Daley <ld@...> wrote:

> http://github.com/alkemist/grails/commit/fa6bcc1dcda4cf02d61f4269604303950f1a81e6
>
> Disclaimer: this is not the intended final state, the way this wraps the
> previous API is somewhat crude.
>
> Each test type is expected to add a closure variable to the binding named
> “«type»TestsPreparation”. It _must_ return something that supports the
> interface of GrailsTestTypeRunner. This should allow completely different
> test runners to be plugged in easily.
>
> If new test types are JUnit 3 test types, they don't have to do anything.
>
> This _is_  potentially breaking for testing plugins that add new test types
> but the fix is trivial. This also means that in some cases testing plugins
> will have to handle pre 1.2 specially, but again this will not be difficult.
>
> Please let me know what you think.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Luke Daley]

On 29/10/2009, at 10:18 PM, Graeme Rocher wrote:

> Looks like a good improvement, but the removal of this code:
>
> - String testRunnerClassName =
> System.getProperty("grails.test.runner") ?:
> "org.codehaus.groovy.grails.test.DefaultGrailsTestRunner"
>
> Breaks the ability for an IDE to specify an alternative test runner on
> the command line so that progress reports

What do these other IDE test runners do? Is this a strictly JUnit  
thing? Or should this be a hook regardless of what is running the tests?

If you could point me at some info on IDE(s) that use this it would be  
helpful.

GrailsTestRunner is tied to JUnit, which is what I am trying to fix.  
Plugins need to be able to provide their own runner.

> Also as I said previously I am concerned about how we are going to
> handle upgrades. Do you plan to have patches in place for all the
> different testing plugins in time for RC1?

The plugins that I know of are:

• functional-test
• selenium-rc
• code-coverage
• web-test
• easy-b
• spock

First 4 use JUnit so are immune to the change.

easy-b uses it's own version of _GrailsTest  (won't have to after this  
change) so is immune.

I will update the spock plugin. The spock plugin depends on 1.2-M3  
currently, I will be adding backwards compatibility later.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-3]

On Thu, Oct 29, 2009 at 2:21 PM, Luke Daley <ld@...> wrote:

>
> On 29/10/2009, at 10:18 PM, Graeme Rocher wrote:
>
>> Looks like a good improvement, but the removal of this code:
>>
>> - String testRunnerClassName =
>> System.getProperty("grails.test.runner") ?:
>> "org.codehaus.groovy.grails.test.DefaultGrailsTestRunner"
>>
>> Breaks the ability for an IDE to specify an alternative test runner on
>> the command line so that progress reports
>
> What do these other IDE test runners do? Is this a strictly JUnit thing? Or
> should this be a hook regardless of what is running the tests?
>
> If you could point me at some info on IDE(s) that use this it would be
> helpful.
>
> GrailsTestRunner is tied to JUnit, which is what I am trying to fix. Plugins
> need to be able to provide their own runner.

Well the IntelliJ guys asked for the feature and the idea is so that
IDEs like IntelliJ and STS can provide green/red bar support even when
running Grails integration tests (ie visual feedback of
success/failure/progress)

>
>> Also as I said previously I am concerned about how we are going to
>> handle upgrades. Do you plan to have patches in place for all the
>> different testing plugins in time for RC1?
>
> The plugins that I know of are:
>
> • functional-test
> • selenium-rc
> • code-coverage
> • web-test
> • easy-b
> • spock
>
> First 4 use JUnit so are immune to the change.
>
> easy-b uses it's own version of _GrailsTest  (won't have to after this
> change) so is immune.
>
> I will update the spock plugin. The spock plugin depends on 1.2-M3
> currently, I will be adding backwards compatibility later.

Ok sounds like its not a big issue then. Let me know when you're ready to merge.

Regards,
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email