It’s obvious to you now, not to test to the point of diminishing returns. Though, hats off to you for taking an untestable design and saving future developers from headache. If you don’t mind, here are some things I would have done differently:

1. Unit testing UI code isn’t the best use of your time. If you are using the MVC pattern and your Controller is taking the View dependency as an abstraction, as long as your View interface is well-designed, the unit tests on the Controller can be sufficient that the code interacting with the view is doing the right thing.

2. Although harder to count code coverage with, consider BDD (Behaviour Driven Development) to automate the testing of User Interfaces. Cucumber and Appium/Selenium are a great combination for testing iOS, Android, Win32, UWP, and web applications - and my experience can attest to this. One can also argue that depending on the type of project, it could be better to invest more in end-user test scenarios than unit tests. These types of tests are covering what the users and stakeholders are interested in.

3. Shooting for above 90% coverage is going to stop adding value. There are so many a) boilerplate code in some projects, b) pieces that can be unquestionably trusted to work, c) also things which are technically higher effort than reward to get value tests out of. And just make sure there is actually value in any of the tests you write - not just writing tests for the sake of writing tests.

The good news is that most of us who care enough to make sure to add the tests (especially when refactoring is required), will use their best judgment and get the project closer to doing the right thing. Just don’t feel the need to strive for perfection.