What can I unit test in a mobile app?

Question

Some background first: we're developing custom mobile apps, most of them tailor made for B2E scenarios. At the moment, we're only testing manually. I know some people consider this a cardinal sin, but thanks to the maturity level of our developers, we manage.

We'd like to introduce automated testing into our projects (new projects, but ideally also in apps which are already 'live' but where we provide support for). I have a good grasp of what (and how) to test in a UI/End-to-End test, but that seems to be only the tip of the testing iceberg pyramid.

I know technically how unit tests are supposed to work, and the Internet is full of tutorials which explain how to unit test mobile apps. That means: which frameworks/tools you can use depending on the platforms you build for and the IDE you're working with. We use Xamarin, but this question applies to other technologies as well.

My problem is: what can I unit test in a mobile app? Roughly speaking, our apps follow the Model-View-Controller design pattern and consist of the following parts:

• ORM/Database layer. We use a custom ORM framework built on SQLite.NET which itself is tried and tested. I'm not sure how to write unit tests here.
• Business logic. This is actually a part which can be covered by unit tests, and most tutorials on how to unit test mobile apps show a testing example from this domain. However, when I have to write 20 lines of code to produce six orthogonal tests for a simple method which determines the type of a barcode (e.g. if it's an EAN code, a Track&Trace code, a loyalty card number, etc.) which consists of 5 lines of code itself, I get the feeling I'm a bit overzealous.
• Calling external services and processing results. We usually work with WebServices and wsdl.exe generates proxy code for us. Because this depends on an external system, it's hard to unit test but I can probably 'fake' a response. Still, it looks like a lot of work for something where (in our experience) the problem almost always lies in wrong data.
• View controllers / Activities / Fragments (depending on the OS). We're careful to avoid the Massive View Controller anti-pattern; still, these are often the largest parts of our application (well, at least the most work to write). I have the feeling that this is the domain where we can gain the most, but I have no idea how to do it.
• Storyboards / Layout XMLs (again depending on the OS). I'm not sure if this can be unit-tested at all, or that they should be together with their controllers.

I've found some unit tests for ASP.NET MVC but I struggle on how to convert them to meaningful unit tests for mobile apps.

Examples which work only for, say, Android apps built in Java, are welcome; even though they don't match the technologies we use, they can be useful to future readers and I can probably convert them to something we actually can use in our projects.

Answer 1

Think of your unit tests like scaffolding on a building. Everywhere you are going to develop you need a framework of unit testing in order to get it to all parts of the building (app code). So as you approach MVC you want to ensure all your controller methods are unit tested. You want to make sure your models bind to your database properly. Then your automated tests sit on top of that and check the functional implementation.

That being said:

• Data layer unit tests - in general these get grouped with the application/business layer unit tests as the only data manipulations should be nested inside of some API which is done through the application/business layer (as it's custom it might be good to have unit tests that execute all the features of this, but I would combine it with the application/business logic where they overlap.)
• Application/Business logic unit tests is where the bulk will be. Some of your tests will add more code to test it then to write it. Naturally you don't want to go overboard, but the goal is to ensure a solid test coverage so that when you run it in the future your ensuring no pre-existing functionality gets broken by introducing new code. Keep that in mind and if a 1 time 20 extra lines of code helps ensure this, then it accomplishes the goal.
• External Service testing should be treated the same as the Application/Business logic testing. The common practice is to develop mock services which mimic the actual nature of the real service with static returned responses based on requests. This is important to not only ensure the full syncing and understanding of the service, but also to properly execute your code against the service in a matching way. Once you have mock services built you should be able to unit test the external services the same as you do other code that hits the database. (Make sure you mimic the communication and network setup where possible too as that affects timeouts and errors etc...)
• Views with the controller logic is the user standpoint. Yes Unit testing can help here too, but I find that it's easier to do automation in general here as if you execute the functional view it covers the view/controller logic by default. It's important to verify this for coverage though. If you go with unit tests then it's merely calling the controller via the view call method to ensure that the method called works just fine. As you can tell this won't test the actual user interaction part, just the fact that if the controller is called from a view it functions as it should. This is why I say it's easier to combine this with the actual functional automation testing in order to grab the full interaction of the view GUI element interaction as well as the functional call underneath and it ensures the user experience lines up. (This would need specifics for your app and could very easily be it's own question, so if you need more here I suggest you ask this as a separate question and give details of your app structure).
• Story Boards and Layout XMLs - In general the layout xml ties to external interfaces or certain gui structure for the pages. If so, then this technically would most likely fall under functional automation and not unit testing specifically. Unit testing should target the granular components and functional automation targets the user functionality and experience which matches to the use cases and story boards.

Mobile: If you utilize responsive UI then your regular browser testing in various resolutions should work for testing the functionality and GUI. The issue comes with device specific compatibility which is best tested on the device itself. You can utilize emulators (include some of the hardware settings that are needed) or simulators (only the software part of devices) but I still recommend actual device testing for the user experience as usability testing is not fully automatable at this time. There are some companies that offer services for automated testing against setup devices like sauce labs. Selenium with the wire protocol connecting with various platforms like Appium for apple, Android emulator, and Windows emulator can simulate most of the user interactions on those platforms as well as most web browsers. Write the tests once and execute on multiple platforms. (Again this one is enough to be it's own question, if you need more specifics please ask this mobile part separately providing specifics to your application)