I think their definition of automated testing is good. Myself I find unit testing to not be worth the trouble, most unit tests I've seen in mobile apps are just checking obvious inputs for obvious outputs. Unit tests take time away from writing good code, can never be complete (even 100% code coverage isn't 100%), and take time away from working on the most important part of any software, features.

I prefer to spend my extra time writing code that validates all inputs and all possible error conditions, and logging exceptional situations that can't be handled within the error system.

Tests I find valuable are ones that explore performance and data quality issues. For example in my current project the original developers decided to assume our server APIs always return nil data (hopefully with an error) or that they will return perfectly formed JSON, and if not, would crash. The truth is it's unlikely the server doesn't return poorly formed JSON for a "successful" request, but I wrote code to test 3,000 stores with various data inputs just to test a single API to find out if it did.

Of course I"m not writing a server API. If I was, I'd definitely be writing unit tests. But in a mobile app, there is plenty of work to do to improve the app directly that provide far more value than most unit tests can.