Smoke testing

This covers all the areas that need to be thoroughly checked during the code freeze before release as well as how to test them. All of the below should be done firstly in the valid expected way and then in a malicious way with the intent of trying to break the program. All problems discovered should be created as issues on the repository and then (based on severity) will be addressed either before or after the release.

Before doing any of these, ensure you are using an up-to-date version of the code on master and all the settings files are using production settings (assuming you are on the production node).

Checkout

• Ensure that all the resources are pulled down correctly from git. The following should be on each node:
• Linux
  • QueueProcessors/
  • utils/
  • setup.py
  • requirements.txt
• Windows (Webapp):
  • Webapp/
  • setup.py
  • requirements.txt
• Windows (Utility machine):
  • EndOfRunMonitor/
  • utils/
  • setup.py
  • requirements.txt

Unit tests

Run all valid unit tests on the node. These will vary depending on what node you are testing, but can be done with:

pytest <name_of_directory>

This should be an easy way to find quick errors in the setup of the project

Monitors

End of run monitor

• Point the end of run monitor to a fake data archive (via the settings files)
  • You can create a fake archive using the DataArchiveCreator
• Re-install the service using python isis_monitor_win_service.py install
• Start the service
• Update the lastrun.txt file for a given instrument and ensure that the data message is sent (this can be validated in hawtio)
• Repeat this for all valid autoreduction instruments

Queues

• Start both of the QueueProcessors on the linux node using the QueueProcessor/restart.sh
• Use ps aux | grep python to validate that both of these services have started.
• Use the manual submission script scripts/manual_submission_script/manual_submission.py to check that data can be sent through from every instrument.
• Check the database to validate that the runs all made it to the database

WebApp

• Boot up the webapp using Apache see production installation instruction for how to do this.
• Ensure that the webapp is visible from outside of the local environment - e.g. if you go to the URL from another machine
• Test the basic functionality of the webapp:
  • Run inspection
  • Run resubmission
  • All the navigation works
  • New runs appear when the database is changed
• Test the webapp admin content is working

Database

On the machine that hosts the database:

Backup

• Run python scripts/mysql_dump/reset_database_post_cycle.py selecting backup and supplying the credentials for the database you want to reset (when prompted) in the terminal. Note the default database is localhost:3306.
• Check the backup file has been generated at C:\database_backup\cycle_xx_x\cycle_xx_x.sql

Remove

• Run python scripts/mysql_dump/reset_database_post_cycle.py selecting wipe and supplying the credentials for the database you want to reset (when prompted) in the terminal. Note the default database is localhost:3306.

• Check the database to ensure that the tables are empty:

reduction_viewer_datalocation
reduction_viewer_experiment
reduction_viewer_notification
reduction_viewer_reductionrun
reduction_viewer_reductionlocation
reduction_viewer_setting
reduction_variables_instrumentvariable
reduction_variables_runvariable
reduction_variables_variable

validate

• Submit one run per instrument - This is to ensure all the options are valid on the webapp

python scripts/manual_submission/manual_submission <INST> <run_number>