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
