-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mock for specific method is not consistent for different scenarios #25
Comments
@seanhenry Do you know if this is the default behaviour ? |
Hi @gonzaloalu Thanks for raising this issue and sorry for the late reply. What you've described is expected behaviour. The way it works is that it will try to make the simplest unique name for each item. So in your case, you started with a method which was not overloaded so the simplest name Unfortunately the generator can't really know about the history of the generated mocks so it can't tell which was created first. And even if it could, in some cases, it would be impossible to avoid changing the generated name for the original method. For example:
would generate:
then adding a new method to the protocol:
wouldn't be able to keep I hear where you're coming from with using the full signature for the generated names but I think generating verbose names when it's not required would take away from the readability of your tests in most cases. Also, they would have to be more verbose than you're suggesting because you can have methods which have identical parameter labels but different types. So in your example the mock would become:
I do recognise that the current strategy isn't perfect and re-generating that test double would likely have caused your tests to fail but this strategy was a conscious decision to maintain the readability of your tests with an unfortunate compromise of causing the generated names to change if adding an overloaded method. What do you think? |
Hello @seanhenry, first of all thanks for your response and explanation, and sorry for the late response on our part. I agree with you on the part that if we want to support same method signatures but different parameter types, It will be too verbose. ( I don't know another solution for this) But I think that this is not very common scenario. Also, the plugin doesn't support that today either. Despite beign too verbose, I think that the plugin should build the method name with all its parameters. As I told you, we want to be in compliance with the Swift API Design Guidelines, and we found that in a lot of cases it's difficult to understand what method we are calling from the test due to lack of information. Let me give you an example that complies with this reference https://swift.org/documentation/api-design-guidelines/#argument-labels: protocol MyLocationProtocol {
func set(latitude: Double, longitude: Double)
}
class MyLocationProtocolMock {
var invokedSet = false
var invokedSetCount = 0
var invokedSetParameters: (latitude: Double, longitude: Double)?
var invokedSetParametersList = [(latitude: Double, longitude: Double)]()
func set(latitude: Double, longitude: Double) {
invokedSet = true
invokedSetCount += 1
invokedSetParameters = (latitude, longitude)
invokedSetParametersList.append((latitude, longitude))
}
} As you can see We think that having the tool be more accurate when creating the mocks for every method would be more helpful than trying to have them simplified
Maybe this could be toggled in a setting? What do you think? |
Hi, sorry again for the slow reply - I'm very busy with other projects at the moment. You're right, it could be a toggled setting. I'm happy to do this when I find time but it would be great to see some support for this feature. Everybody reading this, please respond with a 👍 if this feature is of interest to you. |
For this protocol:
It generates:
BUT if I add a second, similar method the mock for the first one changes:
Generated code:
Also, I think that mocks should reflect the FULL method signature to better comply with Swift conventions, resulting in something like this:
I'm trying on Swift 5 and Xcode 10.2
The text was updated successfully, but these errors were encountered: