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
<michael.putt...@binarygenetics.com> 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:darrell.deb...@gradleware.com]
> Sent: Saturday, June 28, 2014 9:08 PM
> To: dev@gradle.codehaus.org
> 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 <adam.murd...@gradleware.com>
> 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 <daniel.lacass...@gmail.com>
> 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 <adam.murd...@gradleware.com>
> wrote:
>
> 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
>
>
>
>
>
>
> --
> 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
>
> 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
