On 18 Jun 2014, at 7:19 pm, Daniel Lacasse <daniel.lacass...@gmail.com> wrote:
> Thanks Adam for your insight. I will start with synching up the naming
> convention with the current Exec task and see how we can extract common
> interface later.
>
> As for the name used for package and source set , I will use googletest as
> it's more descriptive in the code.
>
> Finally, I see what you mean about having some kind of base plugin to
> register test suite but I will hold off until the integration is finished.
This is a good plan.
>
> I will start moving forward with this.
>
> ---
> Daniel
> On Tuesday, June 17, 2014 04:28 PM, Adam Murdoch
> <adam.murd...@gradleware.com> wrote:
>
>>
>> On 16 Jun 2014, at 4:06 pm, Daniel Lacasse < daniel.lacass...@gmail.com>
>> wrote:
>>
>>> I want to kick start the discussion for contributing support for the Google
>>> Test framework support. I have identified 3 stories which should give
>>> Gradle a functional support for Google Test.
>>
>> Thanks for writing this up. It would be great to see this addition to the
>> native support. More comments below.
>>
>>>
>>> Story: Specific class type for CUnit binary
>>> This story makes sure that subsequent test framework are discriminated.
>>> - Add class
>>> org.gradle.nativebinaries.test.cunit.CUnitTestSuiteExecutableBinary which
>>> extends from TestSuiteExecutableBinary
>>>
>>> User visible change
>>> - Backward compatibility is kept and the following configure all test
>>> suite binary regardless of there framework.
>>> binaries.withType(TestSuiteExecutableBinary) {
>>> // Target all test binaries
>>> }
>>> - It will now be possible to configure the CUnit test suite binary
>>> individually like this:
>>> binaries.withType(CUnitTestSuiteExecutableBinary) {
>>> // Target only CUnit binaries
>>> }
>>>
>>> Test cases
>>> apply 'cunit'
>>> model { testSuites { mainTest { binaires.all { assert it instanceof
>>> CUnitTestSuiteExecutableBinary } } } }
>>>
>>>
>>> Story: RunTestExecutable can take arguments
>>> This story make it possible to passed arguments to the test binary.
>>> Espacially useful for more advance test framework like Google Test.
>>>
>>> User visible change
>>> - tasks.withType(RunTestExecutable).all {
>>> testArgs '--args-to-pass', '-v'
>>> }
>>>
>>> Open issues
>>> - Is testArgs a good name for the property on the RunTestExecutable task.
>>
>> It would be good to sync up with the Exec/JavaExec/Test tasks in some way,
>> even if it’s to use the same naming scheme for the methods that specify args.
>>
>> We don’t want to implement ExecSpec directly, I think, as things like
>> specifying the executable doesn’t make any sense here. Perhaps we should
>> extract some interfaces from ExecSpec that we can share here and with the
>> Exec task.
>>
>>>
>>>
>>> Story: Google Test support
>>> This story adds support for the Google Test framework.
>>>
>>> Note that the implementation is highly based on the current CUnit
>>> implementation.
>>> - Add class org.gradle.nativebinaries.test.googletest.GoogleTestTestSuite
>>> - Add class
>>> org.gradle.nativebinaires.test.googletest.GoogleTestTestSuiteExecutableBinary
>>> - Add class
>>> org.gradle.nativebinaires.test.googletest.plugins.GoogleTestPlugin
>>> - Add class
>>> org.gradle.nativebinaires.test.googletest.internal.DefaultGoogleTestTestSuite
>>> - Add class
>>> org.gradle.nativebinaires.test.googletest.internal.ConfigureGoogleTestTestSources
>>> - Add class
>>> org.gradle.nativebinaires.test.googletest.internal.CreateGoogleTestBinaries
>>>
>>> Open issues
>>> - Should the package name be 'googletest' or 'gtest' ('gtest' is used for
>>> there include namespace in c++)?
>>
>> I don’t have a strong opinion here.
>>
>>> - Should the C++ source set for Google Test named 'googletest' or 'guest'?
>>
>> I think it should probably be the same as the above.
>>
>>> - How can we refactor CUnit code for reusability with Google Test? The
>>> process is the same - configure test source, create binaries, etc. - but
>>> yet different.
>>
>> Eventually, I think we want to have some way for the plugin to register a
>> new test suite type and corresponding test implementation. Some base plugin
>> would then take care of wiring all the stuff together.
>>
>> Not exactly sure how this would look yet. We need to do something similar
>> for plugins that add language support, so we could wait and see how that
>> looks and reuse the same approach for plugins that add test execution
>> capabilities.
>>
>>
>> --
>> Adam Murdoch
>> Gradle Co-founder
>> http://www.gradle.org
>> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
>> http://www.gradleware.com
>>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
