Develop and implement testing and checks

[caldwellst]

We need to think through how to implement more rousting testing and checks to ensure that Mailchimp isn't overloaded with content (ensuring we are able to auto delete and catch errors for instance), emails are not accidentally sent out, and even that datasets can only be updated/changed through the system, rather than manually in Azure Storage Explorer for instance (that is more an Azure checks/balances, but still applies!).

[hannahker]

Thinking about how we might break this down:

1. Automated checks (GH actions run on push to repo):

• unit tests
• standards for code formatting? (in Python, this might be something like Black)

2. "Manual" pre-release testing:

• visual checks on base maps for all countries
• end-to-end alert simulation, against a number of indicator/country options
  - simulate both alert and no alert cases

[zackarno]

I like it and I think we can add a 3rd category for the "Azure checks/balances".

We don't want someone to be able to go into Azure Storage Explorer and delete the container :-)

[hannahker]

We don't want someone to be able to go into Azure Storage Explorer and delete the container :-)

A good point 😬 What are the access restrictions in place currently for this container?

[caldwellst]

We don't want someone to be able to go into Azure Storage Explorer and delete the container :-)

A good point 😬 What are the access restrictions in place currently for this container?

I don't really know, cause I can't control it I think. I would like a lot of checks and balances on making sure the container remains, making sure specific files can only be adjusted with a specific key that we use for actions, that kinda thing. So definitely agree about that point.

1. Automated checks (GH actions run on push to repo):

• unit tests
• standards for code formatting? (in Python, this might be something like Black)

Yep, agree here, we should follow the Tidyverse style guide, which allows us to also easily use the {styler} package to style our code, and pre-commit to fix it. I usually use pre-commit but had trouble with the R setup because it was finding two installs on my machine. Need to just get it sorted now that we are multiple people working on one repo.

[caldwellst]

3rd category for the "Azure checks/balances".

Agree completely here, and think this needs to be well beyond Signals and a discussions on how we protect the entire Azure structure that Isa and Hannah can put into place.

[zackarno]

2. "Manual" pre-release testing:
   visual checks on base maps for all countries
   end-to-end alert simulation, against a number of indicator/country options

• simulate both alert and no alert cases

I think it could be helpful to separate code for pt 2 (above) as it will not really be automated/included in CRON scheduled alert processes.

For example if I am going to work on generating all the maps for countries (I can) I'd probably try to put this in a notebook somewhere where it won't get confused or touched by other developments? Then if some of that code is useful we can integrate it?

I guess we will eventually have a directory for testing? maybe we should have one for "manual_testing"?

[caldwellst]

Yeah, nice idea for it be separate. I think tests/manual and tests/automatic or some similar division would be good. And we can still have GitHub Actions like described in #70 to re-run the manual tests. Code already exists to run map_test.R for all countries which I've used to test and iterate development of our maps, which with your new PR we can now do testing for the legends.