This message was deleted.

Accessors are only generated for things present by simply applying the plugin without further configuration. So any additional test suites you add cannot get accessors, except if you register them in some plugin you apply maybe.

Yes I know that but the

test

suite registered by default by the testing base plugin does not get accessors also so I don’t see the guarantee that my custom plugin will get them 🤔

Ah, right. I think it only works for extensions and extensions on extensions. But

suites

is a named domain object container and I think for those no accessors are generated. Maybe good candidate for a feature request if there is none yet.

🤔 Hm, I wouldve thought this would fall under “Elements in project-extension containers” mentioned here where the project extension is

testing

and the container is

suites

Hm, maybe I remember wrongly

Usually gradle generated accessors for elements in

NDOC

if they are created/registered in some plugin that you apply. At least it was a case for `TasksContainer`/`SourceSetsContainer`. I prefer to use explicit named/by existing/by getting though. It's not just IDE shows red but it doesn't run/compile if you try to use just

test { .. }

or

test.configure { .. }

?

Thats exactly what I am saying 🙂. That

test

suite is created by the test suite plugin. Still no accessors generated for it. I also used

named

to access & configure it just below

Since you posted screenshot and I couldn't differentiate between absent accessors and IDE not finding an accessor. For example IntelliJ IDEA regularly loses accessors for configurations and I have a lot of red in dependencies config when really all is well

Yeah youre right @grossws. I also faced that issue with IJ / AS before where it doesnt index accessors or something. This screen shot was just to give more info about OP.

Just tried that. Only

TaskContainer.test

and

SourceSetContainer.test

were generated( And I've found no issues on GitHub either about test suites accessors or polymorphic named domain object containers.

Yeah thats the reason for my initial question. Is it by design or is it a bug somewhere in Gradle?

I guess they have to write accessor generator on case by case basis. Currently generated accessors are quite different for different containers (e.g.

*ConfigurationAccessors.kt

even have generated javadoc and generate extension methods for different receivers like `DependencyHandler`/`ArtifactHandler`/etc). Doesn't looks like it's a bug more like just an absent feature ,)

I played with it a bit. I think "Elements in project-extension containers" means containers that are directly extensions on the project, or are extensions on extensions, but the container has to be added as an extension. If I for example have

extensions.add("testSuites", project.extensions.getByType<TestingExtension>().suites)

in a plugin, I get accessors for

testSuites.test

and

testSuites { test { } }

. And if I have

interface Foo : ExtensionAware

and

extensions.create<Foo>("foo").extensions.add("testSuites", extensions.getByType<TestingExtension>().suites)

then I get accessors for

foo.testSuites.test

and

foo { testSuites { test { } } }

. But

suites

is a regular property on the

testing

extension and for that no accessors are generated. So as I said, if there is no feature request already, I guess a feature request to generate accessors for container properties on extensions would be necessary.