Begin to add automated testing

This module has a high level of complexity, integrates with a 3rd party API, and writes (potentially destructive) data to an implementor's data base. Up until now testing of any changes has been ad hoc via drush commands and drupal cron calls.

As the module matures, and especially as the installed user base grows, testing will become more and more critical. Currently, there are over 4 API endpoints implemented and 34 drush commands. Manually testing all of this is already a substantial throttle on development.

We should begin to implement a suite of Drupal standard phpunit tests. The scope of this ticket is not to create all necessary tests, but to create 1) some basic tests demonstrating how to extend the testing, 2) a roadmap to basic test coverage, and 3) a standard means to reject new merge requests that do not include sufficient test coverage.

Discussion:

How should the endpoint mocking be best set up?

What are the fundamental test units to be implemented first?

How do we best test destructive data operations like the duplicate item check?

This will require modelling of a target database with some migrated content.

More...

In order to keep this thread from being too noisy, some of the more exploratory/learning parts of the conversation might be best held elsewhere.