[Feature request] Generate mocks only for annotated classes/protocols about cuckoo HOT 10 CLOSED

Hi, thank you for the kind words, we are glad you like it :)

Anyway, @FilipDolnik came to me with the idea before, but I dismissed it that it is not a good practise to make source know about its tests. However, if you are interested in this feature, we will add it.

from cuckoo.

Yeah, I think that would be awesome.
Consider for example a VIP app architecture. In the ideal situation, classes only have explicit dependencies, defined as protocols. In order to test the class you'll only need mocks for protocols, and not for the classes:

// arrange
let dependencyMock = DependencyProtocolMock()
dependencyMock.getDataHandler = { return someData }
let delegateMock = DelegateProtocolMock()
let testInstance = TestClass(dependency: dependency)
testInstance.delegate = delegateMock
// act
testInstance.doSomething()
// assert
XCTAssertEqual(delegateMock.delegateMethodCallCount, 1)

So you'll want to only generate mocks for selected protocols.
And you'll never need to mock TestClass.
Does this make sense?

from cuckoo.

I am also very thrilled with the work on this library and hope to see it continue to evolve. That said, I'm not sure the value of this feature since mocks are already only generated for files added to build script. This feels bad since it brings awareness of Cuckoo into the code-base when it would be better left as a build step.

@impopappfactory, what capabilities are you lacking today that this addresses? Doesn't the explicit file list work for you? I could see improvements on filters happening there though (i.e. regexes etc. for include strategies).

@TadeasKriz, keep up the good work!

from cuckoo.

@pusolito I would normally have Cuckoo run through all project files (or maybe split that in logical groups/modules e.g. NetworkProtocolMocks/MainMocks/SomeFeatureMocks but still process all files in a given module). And I definitely can't see use case for the generated class mocks.

And I really don't see any drawbacks of bringing awareness of tests into the code, if that only adds attributes to entities we explicitly want to mock. If software is designed such as it uses protocols as boundaries between components, it's assumed these protocol will be mocked in order to test actual implementation.

from cuckoo.

@impopappfactory Would --no-mock-classes setting that would ignore all classes when generating mocks work for your scenario? It is always better if the sources don't know about how they are tested. I suppose we could also add support for whitelisting/blacklisting type name patterns, what do you think?

from cuckoo.

@TadeasKriz Yeah, that would solve given use case. Thanks!)

from cuckoo.

@impopappfactory Please give 43cf00b208a37a9f460ac2d39ea7dbc4c483df7e commit a spin ;)

from cuckoo.

Yeah, looks great, thanks @FilipDolnik! ) I'm currently looking into converting Generator to use templates engine, to make it extensible. I've also got some ideas on how to add support for hierarchies and generics.

from cuckoo.

@impopappfactory Sounds awesome! :) Make sure you work with Generator in this repository and not the old one (which has its own repository).

from cuckoo.

Figured that out, thanks!

from cuckoo.