-
Notifications
You must be signed in to change notification settings - Fork 233
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
[Swift] Generate open classes, methods and mocks #1918
base: main
Are you sure you want to change the base?
Conversation
Maybe this could be split into 2:
The main reason I say this is I wonder if there's a better system for generating the mocks, I wrote up some thoughts in #1920 |
While that's useful under normal circumstances I don't think it applies here as extending current uniffi generated classes for Codable results in an |
The way I understand this, subclasses are useless for anything other than mocking because of the missing backing pointer. As such I don't really see the benefit of splitting the two, especially for nested types in which manually writing mocks would be complicated.
That might very well be but I wouldn't block this PR behind what seems to be a larger discussion. If anything having them already in would be a very good test for the new extension system. The most important part in here imho are the mock templates with everything else being easily moved to some other system |
I was thinking that you could manually write them at the start. I could see it getting pretty tedious, but I thought it would be doable. What do you mean by nested types?
I think this goes both ways though. If this PR is tied to a mocking system, then it depends on us agreeing on what a good mocking system is, if UniFFI should be providing one, would we implement mocking in other languages, bikeshedding on the names, etc. A different way to put it is: what are we committing to by merging this PR? Auto-generating mocks seems like quite a big commitment to me. It would require a lot of discussion and we might not end up landing it. You're suggestion of merging this now with a plan of moving it to be an extension is interesting. I could maybe go for that but I would want more confidence that an extension system was definitely going to happen and we would need to make the plan clear to users. |
Oh sorry, just meant complex setups where e.g. Client needs Room, Room needs Member, Member needs something else and you end up having to mock the world.
I agree and I completely understand your point of view but I'm not sure where that leaves us. Generating mocks at the uniffi layer feels very natural (as the implementation for this PR hopefuly proves) and quite useful for anybody wanting to test downstream. With it hidden behind a different command maybe we don't need a strong commitment for fully fledged extensions or to support all the languages. Might even be good for gauging if other users would be interested in having something similar. Generating them externally, after the fact, would be the other option but it feels unnecessarily complicated in comparison. |
#1975 means we have the open classes/methods, with swift and kotlin parity which is great for tests. So I guess this issue is now just about the mocks? |
This PR is the Swift version of this Kotlin PR, as it makes the concrete type open.
Making the concrete types
open
allows them to be extended to write mocks, but there is still a lot of code to be written to extend classes before writing a unit test. That's why this PR also includes the ability to generate Swift mocks directly fromuniffi-bindgen
.Changes made to generate mocks:
generate_mocks
function is now exposed inlibrary_mode
, it uses a newMocksGenerator
which is used to render mocks (seewrapper_mocks.swift
template)open
change, this will also work if the mocks are placed in the client application instead of being packaged with the uniffi generated classes).generate_mocks
is called.Here is an overview of what a mock class that has been generated will look like: