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
Additional features #4
Additional features #4
Conversation
* InstalliOSApplication * UninstalliOSApplication * LaunchiOSApplication * TestiOSApplication
3008989
to
6bd8269
Compare
Thanks for all the contributions @sushihangover. I need some more time to think about this particular PR before merging (since it surfaces public API changes). In the mean time; can you share with me some insights as to how you're using the addon? Also, all of your commits have been atomically perfect - would you like to be a co-maintainer of the repo? |
Geoffrey,
My usage pattern of this Cake addin (w/ the additional APIs): In a continuous deployment environment (devops-style) I am faced with the issue that all mobile devs have, unit testing on devices. You can only mock the environment so much before you have to involve the actual final deployment platform (via real devices and/or simulators|emulators). I almost always use four layers of testing with
As far as no. 2 goes, I've seen so many devs mock out platform functions in order to unit test their apis off device via no. 1 and then wonder why the platform is not responding properly. IMHO, this is such a wrong approach to testing, I get sick to my stomach when I see it done. The case of Android alarms that are not time-based deterministic due to the OS optimizating battery life and only propagating changes to a group of app that need that info in a single broadcast per cycle pattern, the fact that iOS's To bring it back to this project and I am using it as one of a series of required criteria for submitting commits/pull requests before allowing those changes to ripple up through a chain of tiered automated unit testing that start on a small CI and mobile test cloud before allowing it to get to the full-blown test cloud. Just yesterday it blocked 6 pull requests due to iOS specific code mistakes that would have normally consumed about 3 hours of private mobile cloud time at $500/hour, over a year we are expecting it to save a minimum of 120 hours on cloud time, we are also doing with Android AVDs, and macOS VMs and are seeing a saving $200k a year in test hours. Anything that can make platform-specific unit testing on a device or simulator|emulator easier, this project is one of those, is worth it. I even started adding it to one of my public projects Wow, way too long a reply, should a blog post... 👀 -Robert |
Rob, I would love to have you as a maintainer/lead. Three perfect pull-requests (fine grained) and you are passionate about the exact reason why this library was created. To E2E test switch (i.e. platform) assemblies in a unit test application on on-device simulators to test against regressions which only show when running on-device. As you say, it's not 100% perfect there are differences in how the compiler outputs for ARM vs x86 and how the linker behaves but running unit tests on simulator catches the majority of silly regressions. Your thoughts/logic of using this as a way to penny pinch, pounds in the cloud needs to be written up into a blog post - it's on the bleeding edge and would be a good talk at a usergroup or Xamarin Evolve nudge - I haven't seen anyone thinking or talking along these lines yet. This library was made to solve problems I have w/ReactiveUI (similar to what you experience with RealmThread) as a framework author but it's now clear that there is immense value (savings $$$) downsteam at the application level. :) Feel free to add whatever features that you need to the library without my approval, but always please do it via a PR workflow so changes are conducted in the public arena. Check your email for an invite from GitHub, NuGet & AppVeyor. |
Add features to allow unit testing on simulator
This builds upon pull request #3 & #2
Review the
[unitest.cake](https://github.com/ghuntley/Cake.AppleSimulator/blob/6bd82694372f6c3eccf6052ef1b14b5385e41db3/unittest.cake)
on performing xUnit/NUnit for Devices testing...There are two core Tasks (with supporting Action-based aliases) that show the basics:
Unit testing on the iOS Simulator boils down to a fairly simple Task: