On the assumption that in 99% of cases the sources for a test component are
implemented on top of a single framework, I think it's probably better to
use a consistent: "src/MyComponentUnitTestSuite/c" instead of
"src/MyComponentUnitTestSuite/cunit" and
"src/MyComponentUnitTestSuite/googletest".
1. So the identification of a source set as "test sources" is that it
belongs to a test suite component, rather than the name/type of the source
set.
2. We might also want to change the default name of the TestSuite
automatically created for a native component. Perhaps this component should
be made explicit, just like regular components, rather than implicit based
on the plugin applied and the available components. So we'd have a DSL like:
libraries {
myLib
}
testSuites {
myLibUnitTest {
testedComponent = libraries.myLib
}
}
It would be easy to add a conventional plugin on top of this for the common
case of a project with 1 library + 1 unit test suite.
Both 1. and 2. will involve a breaking change to the CUnit support. I think
that's fine as long as it's documented.
Daz
On Sun, Jun 29, 2014 at 8:23 AM, Daniel Lacasse <[email protected]>
wrote:
> 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
>
--
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
