Got it what is missing is project.evaluate() which will *evaluate* the
model (for lack of better term).
On Thu, Jun 26, 2014 at 10: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
>
--
Daniel
