I can see some confusion there. I was planing to go the same route as CUnit
which is:
sources {
${componentNameUnderTest}Test {
googleTest(CppSourceSet) {
srcDir....
}
}
}
The plugin would automatically create the CppSourceSet name googleTest. I
see a couple advantage to this. If you migrate from one test framework to
another (because nothing is an actual standard in the native world), you
can have source sets of different framework co-exist inside one component
that follow a set convention.
I found that it make sens to put the source set for the test code under a
specific name, that way when you browse your source layout, you clearly see
that src/*Test are all test component and that src/*Test/googleTest or
src/*Test/cunit are the code for each respective test framework.
Any thought, comment, etc.
On Sat, Jun 28, 2014 at 6:48 PM, Adam Murdoch <[email protected]>
wrote:
>
> Personally, I think it would be better to use ‘src/test’ rather than
> ‘src/${nameOfTestFramework}’. Otherwise, we’re expecting things like
> ‘src/junit/java’ and ‘src/testng/java’ and ‘src/spock/groovy’.
>
> To generalise things a bit, the source directory name should be
> ‘src/${nameOfTestSuite}’ where a test suite has-a test framework associated
> with it.
>
> On 29 Jun 2014, at 7:41 am, Michael Putters <
> [email protected]> wrote:
>
> 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]
> <[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]>
> 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]>
> 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]> wrote:
>
>
> On 18 Jun 2014, at 7:19 pm, Daniel Lacasse <[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]> wrote:
>
>
>
> On 16 Jun 2014, at 4:06 pm, Daniel Lacasse < [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
> 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
>
>
>
>
>
>
>
> --
> 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
>
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> CTO Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
>
>
>
--
Daniel
