Just one remark (but maybe I’m understanding the design note wrong):
Should the C++ source set for Google Test named 'googletest' or 'gtest'?
Assuming that means something like:
sources {
googletest/gtest {
cpp {
}
}
}
Wouldn’t it be nicer to have something more generic like
sources {
test {
cpp {
}
}
}
Which would default to a /src/test/cpp path (similar to java’s src/main/java
and src/test/java). And then pick the right tool based on the applied plugin. I
expect people rarely use both frameworks in the same project (and they could
still customize the behavior if that’s the case).
Anyway, just my two cents…
Michael
From: Daz DeBoer [mailto:[email protected]]
Sent: Saturday, June 28, 2014 9:08 PM
To: [email protected]
Subject: Re: [gradle-dev] Google Test Support
Hi Daniel
Thanks for the pull request. I've cherry-picked your commit, and added these
design notes to
https://github.com/gradle/gradle/blob/master/design-docs/testing-for-native-runtime.md.
Looking forward to more contributions!
Daz
On Fri, Jun 27, 2014 at 6:06 PM, Adam Murdoch <[email protected]
<mailto:[email protected]> > wrote:
Take a look at, say, AbstractNativeComponentPluginTest and its dsl() method.
It’ll let you do a snippet of build script and take care of making sure
everything has been configured. Perhaps we refactor out an abstract class with
this dsl() method on it.
On 27 Jun 2014, at 12:29 pm, Daniel Lacasse <[email protected]
<mailto:[email protected]> > wrote:
I always had trouble to understand how the ModelRule work and now, trying to
make my initial test fail before coding the first story, I'm still having a
hard time working with the ModelRule. I have the following test case:
def "create correct binary type are created for the test suite"() {
given:
project.plugins.apply(CPlugin)
project.libraries.create("main")
when:
project.plugins.apply(CUnitPlugin)
then:
def binaries =
project.getExtensions().getByType(TestSuiteContainer).getByName("mainTest").binaries
def expected = [CUnitTestSuiteExecutableBinary.class]*binaries.size()
def actual = binaries.collect {it.class}
expected == actual
}
The idea is to verify that all binary for the mainTest component - which should
be a cunit testSuites - are in fact of the type CUnitTestSuiteExecutableBinary.
Unfortunately, binaries is empty because the binary creation happen inside a
ModelRule.rule. How can I force the creation of the binaries from this code to
have my expected result? Or, what other way can I achieve the expected result
of this test?
Thanks for the clarification and help,
On Thu, Jun 19, 2014 at 10:13 AM, Adam Murdoch <[email protected]
<mailto:[email protected]> > wrote:
On 18 Jun 2014, at 7:19 pm, Daniel Lacasse <[email protected]
<mailto:[email protected]> > 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 <[email protected]
<mailto:[email protected]> > wrote:
On 16 Jun 2014, at 4:06 pm, Daniel Lacasse < [email protected]
<mailto:[email protected]> > 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 <http://www.gradle.org/>
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com <http://www.gradleware.com/>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org <http://www.gradle.org/>
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com <http://www.gradleware.com/>
--
Daniel
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
--
Darrell (Daz) DeBoer
Principal Software Engineer, Gradleware <http://gradleware.com>
Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA:
<http://www.gradlesummit.com/> http://www.gradlesummit.com
