Essential testing approaches for Ionic

October 29, 2017, 12:32 pm Categories:


Testing, like documentation, leaves most developers with one of two responses: they either love it or they hate it.

Whether you're a die-hard advocate for putting your code through unit testing, continuous integration tests and usability testing (to name but a few higher-level approaches that might be taken) or simply a developer who chucks in a few console logs here and there as a bare minimum for testing there's no escaping the fact that your code will need to be tested.

Over the course of this article I want to share with you, from my experiences developing for mobile, what I think should be your minimum testing 'toolkit' for Ionic. I won't be covering usability testing, continuous integration tests or more involved tools and approaches that larger development teams would typically use.

Neither will I cover TDD/BDD, Agile or similar methodologies as I feel they are often 'overkill' for the lone developer as the cost-benefits of implementing these are debatable at best (some of you may disagree with that assessment and, if so, that's fine - follow what works best for yourself).

Feel free to share your thoughts, suggestions or disagreements with what is written here (particularly if you feel a particular technique and/or tool has been omitted or overlooked).

1. The browser is your friend

Modern browsers, with their almost consistent cross-platform support for JavaScript and CSS, make developers lives increasingly easier than was the case a decade or so ago.

I started web development back in 2002 during the Flash MX days (which probably makes me something of an old-school dinosaur compared to some of the developers who visit this website) and browser support was extremely limited for code testing (which is one reason why I developed in Flash as JavaScript/CSS was NOT supported equally - or anywhere close to - across the browsers of that era).

Nowadays the latest browsers ship with developer friendly features such as:

  • Network Inspector - analyse network requests and resource download times
  • Timelines - record/measure execution times for http requests, timing the layout/rendering of page elements, gauge JavaScript performance of events, loops etc
  • Resources - allows the inspection of different assets, such as HTML, stylesheets, images etc that are part of an application
  • Debugger - provides tools for developers to set breakpoints within their code and run/test that the selected area of code is performing correctly
  • Console - a logging utility where code values can be printed to the screen

I'm a huge fan of Safari's developer tools but Google Chrome is most developer's choice of browser for obvious reasons (their testing tools and developer plugins are pretty hard to beat). That said Firefox, MicroSoft Edge and Opera (which is almost always surprisingly under-rated amongst developers) are no slouch either.

As with most things development - pick the browser that works best for you and run with that regardless of what's popular or fashionable.

Ionic developers can benefit from using these browser tools by running ionic projects with the following Ionic CLI command:

ionic serve

This will then launch that ionic project in their system browser allowing the code to be analysed using any of the previously mentioned browser features such as Timelines, Debugger or the Console for example.

The only downside of browser testing is that you WON'T be able to run Ionic Native/Apache Cordova plugins within a browser environment.

To get around this limitation read the following article I wrote on Native Mocks.

2. Console logs

The Console API provides a number of methods that allow developers to test their code in the following ways:

  • Inspect variables and values by logging those to the screen
  • Explore the structure and content of multidimensional arrays, maps and similar complex objects in JavaScript/TypeScript
  • Perform benchmark tests for code execution/performance

For such a deceptively simple API the flexibility and assistance this provides is invaluable for developers looking to test that their code is firing off as expected.

Gone are the days of using JavaScript alerts to see what values might be returned in a given block of code (note to new developers - NEVER use a JavaScript alert in any type of loop...unless you want to annoy your team members!)

I'm a huge advocate of using console API methods during development (I actually like to test my code as I'm developing rather than scheduling tests between development) as they are quick/simple to implement and provide invaluable feedback on what is happening with the code (or not!) at any given location in my scripts.

In particular I like to use the following methods for testing my scripts:

  • console.log() - simple outputting of variables and values
  • console.dir() - for inspection of arrays, maps, objects and returned data (I.e. from XHR requests)
  • console.profile()/console.profileEnd() - for measuring code execution times/performance

I've written extensively about using different Console API methods and would recommend that you use these, if you aren't already, as an integral part of your development toolkit.

3. Unit testing

Like it or loathe it unit testing is here to stay but even as useful as this testing approach is there are possible drawbacks that aren't as widely discussed as they should be - let's look at these before we explain why you should unit test your projects.

Firstly, there are a lot of developers who fail to understand that unit testing is a discipline in its own right and, unfortunately, it's far too easy to write bad tests without fully understanding the system that needs to be tested (and its requirements).

If the system requirements change this can and often does, unless an agile testing approach is in place, quickly render those previously written unit tests obsolete and impractical (and most developers/development teams simply don't have the luxury of time or budget to rewrite these as and when such system changes occur).

Additionally the time required for writing unit tests can, if not planned/monitored, heavily impact on development related time which has the ironic effect of having to hurry project development which, in turn, carries the high potential of introducing more bugs into the codebase as a result. This is more a consequence of bad time/resource management during the project lifecycle but I have seen it happen and, sadly, it's far more commonplace than you might think.

Finally, unit testing is not a universal panacea for all coding woes - it can't detect all possible logic errors and bugs that may occur in the development cycle (although it can certainly help) - and should be seen as part of a broader testing strategy and not a complete solution in and of itself.

I'm not trying to dismiss the importance of unit testing with what I've written here but I do believe it's important to put that testing approach into context - particularly with some of the more rabid evangelising that I've come across online with developers extolling unit tests and their virtues.

Okay, so with the possible drawbacks mentioned and out of the way why should developers unit test their Ionic projects?

Unless you're a lone developer working on a very basic ionic application with limited functionality (in which case unit testing would, more likely than not, be massively overkill for such purposes) the answer is simple: does your code behave as expected?

You'll be surprised at the assumptions we can make about our code and then find ourselves met by gaping holes in our logic when those assumptions are crushed by bugs we never expected.

A very simple example would be expecting data returned from a remote service to be a particular data type, say a string or boolean, and then finding that actually it was an array or an object.

This is something that a unit test could help catch prior to the code being tested in the browser or being published as part of a build package.

Given the time savings gained by such a test (particularly when it comes to building packages and deploying these to a mobile device) it's a no-brainer to include unit testing as part of our development cycle (just remember the potential drawbacks and be sure to write good tests).

When it comes to implementing unit testing for Ionic projects I recommend using the Jest testing framework which I've detailed in the following articles.

Until the team at Ionic bake unit testing into the framework/CLI by default then Jest is by far the easiest, quickest and most effective unit testing approach I have come across so far.

4. Ionic CLI

When it comes to publishing/running our projects the Ionic CLI, by default, tests our codebase for transpilation errors/warnings such as:

  • incorrect data type declarations
  • constructor initialisation errors
  • missing providers/components/pipes
  • access violations on properties/methods
  • duplicate properties/methods/variables
  • unused properties

Although it's frustrating to see the system terminal displaying CLI errors when attempting to build/run ionic projects it's a huge time saver in the log run.

Similarly we can add the --verbose flag to see what is happening at each stage of an ionic build process like so:

ionic cordova build ios --prod --verbose

This is useful where we might encounter build related errors as a result of software environment related issues (and need to diagnose exactly what they might be) rather than problems with the code we have written.

Note that the --verbose flag can be used with the ionic serve command too.

Finally the ionic serve utility allows us to preview the project within our browser as if it were running inside of iOS, Android and Windows Mobile by adding the -lab flag like so:

ionic serve -lab

5. typeof

I work with a lot of data and the subsequent transformation of that data in my projects so it's important for me to know that what I expect is exactly what I receive.

The typeof operator helps me greatly in this regard.

6. The device itself

I am not a fan of mobile/tablet simulators - even as useful as they are (particularly with the wide proliferation of different mobile/tablet devices and the prohibitive costs of building up such a library of devices) - as they will never truly approximate the experience of using a realworld mobile/tablet (as that is the only way you can know your application truly works on such devices).

Unfortunately there really is no substitute for testing your applications on a physical, handheld device.

I appreciate this might not be possible for students or developers with limited income (and those shiny Apple/Android gadgets don't get any cheaper with each new release do they?)

If you happen to be in such circumstances it might be worth investigating the use of Open Device Lab.

I haven't personally used the service myself so I can't honestly comment on its usefulness but it certainly looks like a promising alternative to relying on the Xcode or Android related simulators.

In summary

I've deliberately chosen the cheapest and easily available resources for testing Ionic applications that are also some of the most effective.

The browser development tools and Console API methods in particular should be the first line in any developers testing 'toolkit' and if you aren't making full use of these then you really need to start now!

I'll be exploring additional ways in which code can be tested for Ionic applications in future articles.

If you feel I've missed something out or overlooked a particular testing tool/approach that should be included in the above article let me know in the comments section below.

If you enjoyed what you've read here then please sign up to my mailing list and, if you haven't done so already, take a look at my e-book: Mastering Ionic for further information about testing Ionic applications.



Post a comment

All comments are welcome and the rules are simple - be nice and do NOT engage in trolling, spamming, abusiveness or illegal behaviour. If you fail to observe these rules you will be permanently banned from being able to comment.