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
