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
