Testing & Verification

Once the code for the scripts has been "completed", we can proceed to use the "cob-cli test" command in order to test if they are working as intended. Since the files we created are new files and do not exist in the server in it's current state, cob-cli test will ask for your permission to create these files on the server. After the files are created, we can go through our normal testing procedure, and once we feel that the testing is complete, exiting out of cob-cli test will restore the files in the server to their previous state, leaving the server untouched.

Testing procedure

Now for the actual testing procedure, once we have placed our scripts on the server temporarily we will need to use SSH in order to access the server, and we can begin testing using integrationM. As was covered in The CoB Architecture (opens new window), there are a variety of situations that create a message in integrationM, such as the creation and updating of instances in recordM.

$> cob-cli test                                                          ─╯
Start testing… 
Checking test conditions for *******.cultofbits.com
  ✔ Check connectivity and permissions
  ✔ Check there's no other 'cob-cli test' running locally
  ✔ find out branch-for-HEAD
  ✔ find out SHA for last-deploy on specified server
  ✔ git stash --include-untracked
  ✔ git checkout SHA for last-deploy
  ✔ Apply last enviroment specifics
  ✔ Check last-deploy == serverLive
  ✔ Undo last enviroment specifics
  ✔ git checkout branch-for-HEAD
  ✔ git stash pop

Checking changes... 

Changes that will be done in hmarcelino.cultofbits.com:
 change integrationm/scripts/some-script.groovy

 Continue? [y/N] 

Testing the first script

In the case of the first script, in order to test we simply need to fill in the "Start Date" and "Duration" fields, then save the instance. If when we reload the page, after saving, the "End Date" field is filled in automatically, then we know our script is working.

If the field hasn't been automatically calculated and filled, it indicates a potential error in the code. To diagnose the issue, we can refer to the IntegrationM Log and the RecordM Log. To access these logs, we'll need to SSH into the server in question and then utilize the commands im-log or rm-log, respectively.

TIP

The location of the scripts in the server is "/etc/integrationm/scripts"

Testing the second script

In the case of the second script, testing presents a slightly more complex challenge, as we aim to ensure the functionality of the script responsible for sending email notifications. Instead of following a similar testing method as the previous script, we must first verify that the script functions correctly before deploying it to production. To accomplish this, we can execute the bin/sendMsg2IM contract-management command to send a message directly to IntegrationM. This action simulates the message that our email script would anticipate from the cron job, allowing us to test the email notification ahead of the defined date.

Initially, these tests may yield errors. In such cases, we would also utilize the im-log command to check for error messages and rectify any issues in the code. Once the email is received and the IntegrationM log indicates no errors, we can confidently assert that our script is operational and proceed to prepare it for production.