Do we need ViewInspector and UIUTest as part of the sample apps?

[nickkaczmarek]

Reasonings

Starting this discussion to figure out if we need more dependencies in the sample apps other than SwiftCurrent.

There are multiple reasons I bring this up.

1. Having these libraries seems to prescribe to potential consumers of SC that you will also or should also use these libraries to use SC.
2. While being able to test SwiftUI this way is interesting, it feels like it overcomplicates things (especially when running into errors)
3. Testing using these libraries almost gets into the territory of testing SC instead of testing just the business logic of an app.

1

This is the spot where we're prescribing that a consumer uses UIUTest with the library for testing.

For our test example, we are using a library called UIUTest. It is optional for testing SwiftCurrent, but in order for the example to be copyable, you will need to add the UIUTest Swift Package to your test target.

I think by keeping this in there we are creating a cognitive load where a consumer will either have to use a library they potentially don't need or understand and if they choose not to, we're making them figure out what code they can use and what they can't. I think it would be better for us not to prescribe this.

2

To understand why I think ViewInspector is overcomplicating things, look no further than our views that all include inspectable code embedded into them. This is another cognitive load where we're expecting consumers to either just deal with the external to us library or have to rip it all out to use our examples. Furthermore, if they change something and ViewInspector fails for some reason, it becomes very messy to debug the issues as VI is doing some pretty intense things with memory.

3

I read an article last weekend about testing SwiftUI and the author suggested that extracting business logic from views was his preferred approach. This resonates with me because I think it gets to the core of unit testing. Testing the units of business logic. I feel that what we are currently doing is something more akin to end to end testing or integration testing in that we're testing how views flow into other views. I would assume as a library consumer that SC is already tested and so I really only need to test my business logic and assume that the other bits are going to play out.

Conclusion

I make no arguments against the usefulness of these libraries, but I think they could push people away from wanting to adopt SwiftCurrent and I think that's the most important thing. I think we should be providing as many small examples of how to use SC as we can and ensuring that we aren't using or prescribing any additional dependencies.

I would also go so far as to say that I don't think we need to be testing our examples and should just rely on the testing we do inside of the SC package.

[Tyler-Keith-Thompson]

I agree with most points. ViewInspector and UIUTest introduce unnecessary cognitive load for potential consumers. They're wonderful libraries, but totally irrelevant to pulling in SwiftCurrent.

Philosophically I prefer the very fast nature of using ViewInspector to black-box test behavior from user expectations much more than I like your third point with strict unit tests. It's possible to have perfectly valid and passing strict unit tests and still not have a working app. That said, it's outside our scope of responsibilities and the proposal isn't to change how SwiftCurrent does testing.

That said, SwiftCurrent was using those apps as a dogfooding exercise, which is why they're so heavily tested. Perhaps we should consider not calling them "Example Apps" and hide them away somewhere, but keep them around for purposes of validating the consumer experience of using our library. They've lead to some incredibly valuable insights as we've designed. They've also served as a very valuable testbed for things like UIKit and the few XCUITests we've got.

[nickkaczmarek]

After the last week of debugging _abandon I can definitely see the value in these apps as a way of dog fooding but agree that maybe example app isn't the right term. Perhaps testbed or something like that. And I totally agree on their usefulness, just that they're mega complex if something goes wrong. I think initially I was all for just ripping them out, but now I'm definitely thinking that keeping them around for us is a good idea.

I think we can noodle on this some more and come up with something that helps us and doesn't potentially confuse consumers.