I noticed that generated stub methods are named using an incrementing index: static func stub0(...), static func stub1(...), etc.
This poses several problems:
The index is dependent on the order of initializers in the original type. If the initializers in the initial type are swapped in order, the index of the stub methods change accordingly. So what used to be stub0 will then stub1 and vice versa. This will break all the testing code using the stubs. I believe the order of initializers should not impact the generated code.
This is personal preference, but I find the names .stub0 or stub1 quite jarring at the call site. The number doesn't add any clarity to what the method does, but only clutters the intention of the code.
Since Swift initializers are unnamed, they are disambiguated using the rest of the function signature. Therefore I assume it would be also possible to just use the name stub for every generated method, without there being any ambiguity.
In my very non scientific test, it worked fine once I overrode func stubMethodName(index: Int, count: Int) -> String to always return "stub"
I noticed that generated stub methods are named using an incrementing index:
static func stub0(...),static func stub1(...), etc.This poses several problems:
stubmethods change accordingly. So what used to bestub0will thenstub1and vice versa. This will break all the testing code using the stubs. I believe the order of initializers should not impact the generated code..stub0orstub1quite jarring at the call site. The number doesn't add any clarity to what the method does, but only clutters the intention of the code.Since Swift initializers are unnamed, they are disambiguated using the rest of the function signature. Therefore I assume it would be also possible to just use the name
stubfor every generated method, without there being any ambiguity.