09 18 2024 Meeting

REDCap Con 2024

• Announced during plenary that v13.1.37 and v13.7.15 are passing and ready to go
• Did not post anything on Community about this, intentionally
• Wanted a controlled release and to make sure we had our documentation taken care of
• Hoping people will be pleased with the documentation solution

Documentation v13.1.37 https://github.com/aldefouw/redcap_rsvc/releases/tag/v13.1.37-ABC

To Do: Short term:

• Apply same documentation strategy for 13.7.15

• Once documentation is done, will post to Community Site

• Will also post an explanation for what the release means and WHY we are behind the manual tests (always the next question)

• Long term: Hoping to have the CI/CD pipeline automatically upload the videos and link them to the documentation in future version 14.5.5

Next Steps:

RSVC Feature Tests

• Met with RSVC leadership yesterday to discuss how we can get manual and automated tests in alignment
• END GOAL: Manual and Automated Features will be the same

We have developed a strategy to make this happen.

The first two steps are the following:

1. File Structure Alignment - manual and automated need exact same file structure, it has diverged
2. Feature Test Formatting - run both manual and automated feature tests through the same formatting using VS Code

Once we have file structure and feature test formatting alignment, it puts us in position to have a clean difference report. This will help us to understand what features we need to specifically discuss the divergences on.

From there, we will figure out an agreed upon solution for each feature test that needs re-alignment.

If it isn't obvious, what that does is put us in a position where we can shift the responsibility of RSVC Feature Test writing off from this ATS subcommittee.

From there, the software developers in this group can start focusing on the additional needs of the Consortium including but not limited to External Module feature testing strategy and how to support specific Institutional Testing.

RCTF Package

One of the ways that we ensure people are buying into using our framework to test for External Modules and Institutional customizations is to now ensure robustness in our framework and reduce the surface area of our code.

• Initial release: strategy was to develop concrete methods and "get it working"
• Future: Concrete methods identified, therefore, we know what level to abstract the code to reduce our code surface area (~7500 lines of code)

Action Items:

• Identify what and where abstractions are for the step definitions
• Develop a comprehensive table that maps what the abstraction looks like (i.e. button | link | checkbox) ( click | type | etc)
• Create tickets to specifically and iteratively abstract the behavior for step definitions in question