samedi 30 janvier 2016

Unit Testing Strategy, Ideal Code Coverage Baseline

There's still not much information out there on the XCode7 and Swift 2.0 real-world experiences from a unit testing and code coverage perspective.

While there're plenty of tutorials and basic how-to guides available, I wonder what is the experience and typical coverage stats on different iOS teams that actually tried to achieve a reasonable coverage for their released iOS/Swift apps. I specifically wonder about this:

1) while code coverage percentage doesn't represent the overall quality of the code base, is this being used as an essential metric on your team? If not, what is the other measurable way to assess the quality of your code base?

2) For a bit more robust app, what is your current code coverage percentage? (just fyi, we have hard time getting over 50% for our current code base)

3) How do you test things like:

  • App life-cycle, AppDelegate methods
  • Any code related to push/local notifications, deep linking
  • Defensive programming practices, various piece-of-mind (hardly reproducible) safe guards, exception handling etc.
  • Animations, transitions, rendering of custom controls (CG) etc.
  • Popups or Alerts that may include any additional logic

I understand some of the above is more of a subject for actual UI tests, but it makes me wonder:

  • Is there a reasonable way to get the above tested from the UTs perspective? Should we be even trying to satisfy an arbitrary minimal code coverage percentage with UTs for the whole code base or should we define that percentage off a reasonably achievable coverage given the app's code base?
  • Is it reasonable to make the code base more inflexible in order to achieve higher coverage? (I'm not talking about a medical app where life would be in stake here)
  • are there any good practices on testing all the things mentioned above, other than with UI tests?

Looking forward to a fruitful discussion.

Aucun commentaire:

Enregistrer un commentaire