Skip to content

10 11 2023 Meeting

Jump to bottom
Adam De Fouw edited this page Oct 11, 2023 · 16 revisions

v11.1.5

  • I have been looking at how many features are left - looks like it might be a fairly small effort to finish
  • Located features that were written for basically all of the remaining issues that were open ( https://github.com/aldefouw/redcap_cypress/projects/4 )
  • I'll try to work on merging in these features and see what the outcome is
  • Don't want to spend a ton of time on feature tests for a version that is known to have security vulnerabilities
  • Still would like to cross the finish line on this so we can release

Rapid Validation Project (v13.1.37 + )

MANUAL VALIDATION PACKAGE

  • For those of you who are unaware, the Manual Validation package is now written completely in Gherkin as well
  • This will make our efforts way easier in the long run

SCOPE

  • One major change from the v11.1.5 feature tests is that the SCOPE of the Step Definitions has been carefully honed

GUIDING PRINCIPLE:

  • The major guiding principle is HUMAN READABILITY

  • If our starting point is that humans must be able to define the Gherkin

  • We need to assume that someone can perform the test with essentially zero context or very little context and essentially no or very little REDCap experience

  • Step Definitions - practical implications:

  • Ironically, this actually helps us to better follow some best practices like the Single Responsibility principle

  • Step Definitions for v13.1.13 + tend to do only one thing at a time (e.g. click a button, type in a field, click a link, check a value, etc.)

  • On version 11.1.5 I think some of our Step Definitions started trending towards developer convenience

  • Completely understandable given how many we had to define

  • However, I think doing a single thing well is actually a better strategy in the long run even for maintenance

  • TLDR: This means that some of the Step Definitions that were written for v11.1.5 were redefined. There are a lot of new Step Defintions.

MANUAL VALIDATION PACKAGE CHANGES:

ATS Plans

Working Meetings

  • Will resume soon

  • Will function as training sessions this time instead

  • I will run through a feature test conversion from the manual process together

  • As people get more comfortable with the process, we can start onboarding others to help with the feature tests again


  • I am anticipating that groups like Cambridge might be willing to help

  • What would help me plan for the next steps is to know what questions you all have about the process

  • It's hard for me to know this right now because I've been working behind the scenes for many months so I am very close to the process

  • Now that we have a rough idea of what our workflow looks like, I want to involve the subcommittee again

VERSIONS:

  • We will focus on v13.1.37 and then v13.7.15, and then next version ...

Feature Test Assignment - I want to issue feature tests assignments like we were before through GitHub directly - Hoping to have more info about that by our next meeting - Planning to create issues using GitHub API to link the files without having to do it manually because that is a massive headache administratively

FUTURE / LONG TERM PLANS:

  • RCTF will eventually become an NPM package where you can write whatever features you want on top of our supporting Gherkin steps

  • This will divorce the need for our repo to have specific features inside the specific repo

  • Instead, we'll have a package that runs the Gherkin-formatted feature tests behind the scenes

  • It will mean that some of our supporting methods need to have conditional logic to support different behavior depending upon the version

  • We'll cross that road when we get there

  • Opens up some exciting possibilities though ... which I have talked about before ... one of them being able to write tests for things liek External Modules

  • For right now, we want to stay focused on getting these core tests knocked out but in the long run this is something to keep in mind because it will change the scope of what our subcommittee does

  • In the long term, I'm hoping our subcommittee does very little Feature Test maintenance. Sure, we might help write some when new features or functionality become available but I think the more appropriate role for us is the technical maintenance side.

  • Long term, what this package becomes is a set of step definitions. The automated testing subcommittee therefore becomes the supporting group who helps with the ongoing maintenance of step definitions

  • Could include modifying or updating step definitions to support new versions of REDCap

  • Could also include (hopefully rarely) creation of new step definitions when new functionality requires it

REDCap Cypress Test Framework

Getting Started

Additional Learning

Core Testing Initiative

Writing Tests in Gherkin

Clone this wiki locally