Generated mocks in test target missing @testable annotation against main target about apollo-ios

[michaelloo]

Thank you @calvincestari ! That worked 👍

Whilst it fixes my problem, I wonder if we still would want the ability to specify whether the import of the generated mocks should have @testable in cases where we dont the mocked models to be public?

Using the Mocks would actually be beneficial but cannot be used without public graphql models.

[calvincestari]

We used to be able to create test data for the generated GraphQL models using the initialiser, but as referred to in the migration document, we are meant to now use Mocks and ApolloTestSupport instead.

I think the selection set initializers config option was built after the migration guides. That may be what you're looking for?

[calvincestari]

@michaelloo do you mind sharing your codegen configuration so I can see how you're putting things together.

[AnthonyMDev]

Yeah, I do agree with you @michaelloo. I'm thinking we can determine if the generated models will be public from the configuration and just know to add @testable or not without needing another new config option.

[michaelloo]

@calvincestari here is my latest config (with some obscured params):

{
  "schemaNamespace" : "XXXSchema",
  "schemaDownload": {
    "downloadMethod": {
        "introspection": {
            "endpointURL": "some.url/graphql",
            "httpMethod": { "POST": {} },
            "includeDeprecatedInputValues": false,
            "outputFormat": "JSON"
        }
    },
    "downloadTimeout": 60,
    "outputPath": "./graphql/"
  },
  "input" : {
    "operationSearchPaths" : ["**/*.graphql"],
    "schemaSearchPaths" : ["**/schema.json"]
  },
  "output" : {
    "testMocks" : { "none" : {} },
    "schemaTypes" : {
      "path" : "./GeneratedFiles",
      "moduleType" : { "embeddedInTarget" : { "name": "XXX" } }
    },
    "operations" : { "inSchemaModule" : {} }
  },
  "options": {
    "cocoapodsCompatibleImportStatements": true,
    "selectionSetInitializers": {
      "localCacheMutations" : true,
      "namedFragments" : true,
      "operations" : true
    }
  }
}

I had "testMocks" with "absolute" configuration in there when trying the Mock out

---

@AnthonyMDev that could work if that is the assumption we take that if the accessModifier for the GQL models are not public, then the mocks are purely for testing. That will couple them together more but might not be a bad thing I guess.

Is adding another AccessModifier case called testable that we can pass to the existing testMocks.absolute config? Although this might also not be ideal because it means you could actually create GQL models with @testable as well and that might not make any sense 🤔

[calvincestari]

Is adding another AccessModifier case called testable that we can pass to the existing testMocks.absolute config? Although this might also not be ideal because it means you could actually create GQL models with @testable as well and that might not make any sense 🤔

TestMockFileOutput and SchemaTypesFileOutput.ModuleType share the same enum so I don't think an internal case will work there and it is worth duplication of the enum when we can work with assumptions instead?

@AnthonyMDev that could work if that is the assumption we take that if the accessModifier for the GQL models are not public, then the mocks are purely for testing.

Our view is that test mocks are purely for testing; that was the intent of their design. There is also a future where test mocks are deprecated.