I like this approach, and I use it a lot in my Objective-C to swift conversions. For new code (or legacy apps without testing infrastructure) I tend to approach testing first from the top down with Functional tests (uix button pressing) and defer the majority of unit testing until something is broke. If I find a bug in a subsystem than I almost always but a unit test around it. I hate the idea of fixing something twice.
The mocking component is a critical component in this. My networking constructors dependency inject the network config ( PRODUCTION, STAGE, MOCK ). Over the past few months I have been trying different strategies on the mocking. I have done it with local embedded JSON files for the mock network endpoint and also localhost swift server, serving the JSON mocking file overt the network. I like testing across the wire instead of responding with mock data from inside the app because ( as was pointed out in the article ) the functional user experience is often in response to the network response error and response duration.
In the past I have rolled my own swift mocking server, but I will give Embassy a try over the next week. Its always nice to have this type of thing in your developer "tool belt" for future projects.
Comments
I like this approach, and I use it a lot in my Objective-C to swift conversions. For new code (or legacy apps without testing infrastructure) I tend to approach testing first from the top down with Functional tests (uix button pressing) and defer the majority of unit testing until something is broke. If I find a bug in a subsystem than I almost always but a unit test around it. I hate the idea of fixing something twice.
The mocking component is a critical component in this. My networking constructors dependency inject the network config ( PRODUCTION, STAGE, MOCK ). Over the past few months I have been trying different strategies on the mocking. I have done it with local embedded JSON files for the mock network endpoint and also localhost swift server, serving the JSON mocking file overt the network. I like testing across the wire instead of responding with mock data from inside the app because ( as was pointed out in the article ) the functional user experience is often in response to the network response error and response duration.
In the past I have rolled my own swift mocking server, but I will give Embassy a try over the next week. Its always nice to have this type of thing in your developer "tool belt" for future projects.
Thanks for the contribution envoy.