search

Brightify / Cuckoo

Boilerplate-free mocking framework for Swift!
MIT License
1.67k stars 174 forks source link

Compilation error for ignored class #136

Closed kurtguenther closed 1 year ago

kurtguenther commented 7 years ago

I have an input file that contains two protocols and one class. I would like Cuckoo to ignore the class.

Despite running cuckoo with the options --no-classes and --exclude ClassName I still get errors from Cuckoo trying to mock the class. The class contains private variables with inferred types (e.g. private let foo = true) and Cuckoo gives the error:

error: Type of instance variable frames could not be inferred. Please specify it explicitly. (/path/to/input.swift)

I would expect that Cuckoo doesn't even do these checks if it's told to ignore this class.

TadeasKriz commented 7 years ago

This is weird, it should really ignore those declarations (either all classes or those with excluded names). This is reported to console and it ends with non-zero result code?

nxtstep commented 6 years ago

@kurtguenther Could it be that the classname you're trying to exclude has a generic type definition?

kurtguenther commented 6 years ago

Nope, they are standard non generic classes.

MatyasKriz commented 6 years ago

I just checked the code. The issue is that Cuckoo tokenizes by file, not by component. Therefore the file is tokenized (and the tokenizer complains to stderr about the unknown type) and after that the token is removed from the token collection.

From my standpoint I see 2 solutions: either pass the info that we wish to keep classes alone as well as excluded names (and the regex with the new version) which would make things really ugly and violate DRY quite a lot, because we're doing the checks in the mock generator as well. The other, cleaner, solution is to remove all the stderr printings from Tokenizer, make it shut up about the errors it encounters and let the mock generator report them after filtering out the tokens that don't belong with the others. I think the second solution is possible to do without any changes to the Token. If we wanted the Tokenizer to create the messages, we could create some Error? to the Token which would get printed by the mock generator after filtering the tokens. The second solution needs to iterate through the tokens one more time and I think it's a better option over doing the same filtering twice.