R2.4: Add dependency testing to the automation use case

[pedrohbraga]

Reviewer 2 comment:

R2.4. I suggest adding a discussion on dependency testing within or following the paragraph on Automation (Lines 373-382). This is a project “ecosystem” phenomenon that comes from collaboration, where you build your project on the work of someone else. As projects change over time, they can alter other projects. Software engineers have been working on this challenge for a long time in distributed teams where different parts of software are being built by different programmers. Checks can be done automatically within the software engineering framework (see Pasquier et al. 2017 https://www.nature.com/articles/sdata2017114). Beyond detection, any major changes can be detected and presented without additional work from the user via features like badges (https://shields.io/) within the project page (e.g., README).

Recommendations during the revision:

1. When performing changes addressing this comment, please recall this issue (using # followed by the number of this issue) in the pull request; and,
2. Clearly justify changes in the final comment of the pull request (to allow us to revise the manuscript in time).

[wavingtowaves]

I do not think we should make this addition. While dependency testing is important for sharing code widely, it falls on the more technical end of the spectrum. We have been encouraged by reviewer 1 in #277 and #278 to reduce jargon and gear our work toward entry-level researchers. Dependency management is out of scope for that group.

[pedrohbraga]

Hi. I agree that both automation and unit dependency testing are more advanced tasks, which many users may not require. Still, it has been more and more encouraged as a way to mitigate errors across research practices. The narrative already incorporated these components when we discussed about validation and verification, but perhaps in a less clear way. Without adding complexity to the narrative, I added a few words to mention that automation can aid the testing of research code and the implementation of workflows for the interpretation, integration and usage of data and software across different sources, and included two citations (one of them being the one that the reviewer provided).