Harden the script against API changes.

[bjohas]

Given this note:

Google adds features to Tasks, but does not provide access to that information for third-party apps
The new Tasks allows a user to set a time for a task, and allows for a task to be repeated, but that information is not available via the API, so I cannot export or display the time or repeat info for a task. These features have been available in Tasks since March 2019, but as at October 2019, I am unable to export that data for my users. There is an open issue for this at https://issuetracker.google.com/issues/36759725#comment40

and given this https://github.com/Google-Tasks-Backup/tasks-backup and https://github.com/Google-Tasks-Backup/import-tasks (defunct):

Should we think about having certain test cases? I might make a gtasks list that has all the features supported by the script, and then export this list once in a while (or perhaps before every backup?), comparing against the expected results. This would guard against API changes that aren't implemented in the script (e.g., if the subtasks suddenly disappear, we know it's due to an API change.)

The above apps seek to go much further, implementing import as well. That's definitely not the intention for our script. So I'm not sure that sudden API changes pose a major risk, if we monitor?

What do you think?

[Resinderate]

We could do something for this but I would probably advise against it.

They never actually introduced a breaking change, they added a new feature and didn't add the same feature to the API. It's highly unlikely they would add a breaking change without versioning up the API.

In backend systems you generally try to avoid testing external dependencies, you somewhat have to trust the dependency and accept the risk.

We could add an integration test which checks the content of a task for example, and asserts that everything we need is still coming through. It would only be useful as a debugging tool when and if google broke the API though (very unlikely), and running a gtasks backup would likely tell you the exact same issues as a test like this would. (For example, there is no title field on the task). Once you do this, the line is then blurry as to what else you should test which then becomes an infinitely large list. The types returned from each function? Does the Oauth system work when I use it?

Paying the cost of writing the test and then maintaining that code does not provide enough value for it to be worth it in my opinion.