top of page

We created the following types of tests:

Tests

Overview

Worksheet Validation Tests

We converted the CDASHIG PDF to an Excel Worksheet using Adobe Acrobat.

The converted Excel Worksheet had several challenges: 

* It contains all the data in the CDASHIF PDF, not just the Example CRFS and Domains we wanted.  We concluded that it would be difficult to filter out the data that we did not want programmatically.

* It contains multiple spreadsheet header rows, which increased the complexity of extracting the Example CRFs and Domains we wanted.    

 

* Some data in the ExampleCRFs and Domains columns overflowed onto a separate row.  That added to the programming complexity.

To overcome these limitations, we manually created a Worksheet that did not have any column data overflow or multiple Worksheet header rows. Because that was a manual process, we created a test for each manually created Excel Worksheet to validate it. We used the following process for each Worksheet: 

We Created a Dictionary Of Expected Results 

We manually created a dictionary of expected results containing the number of rows in each Example CRF and Domain using the CDASHIG PDF.

We manually created another dictionary of expected results containing the value of each column in the first and last row of each Worksheet using the CDASHIG PDF.  

We Successfully Imported Each Worksheet Into the Database 

That proved that we configured the application correctly and were able to connect to the database and perform CRUD operations. 

It also proved that each Worksheet passed the following Worksheet Edit checks before being imported into the database:

  • The Worksheet has the expected number of columns 

  • The Worksheet Header column names match the list of expected  Worksheet header names

  • The number of rows in the Worksheet does match the expected number of rows that GalaxyeClinical derived from the CDASHIG PDF

  • A Worksheet column value contains the type of data (text  or number) specified in the CDASHIG 

  • The length of the data in each Worksheet column is within the range of the rules that GalaxyeClinical defined for Worksheet columns after reviewing the CDSAHIG PDF.

We Compared The Number Of Rows In The Database  For Each Worksheet To Number Of Expected Rows For Each Worksheet

We wrote a test that fetched the Worksheet from the database and compared the number of rows in the database to the expected number of rows in the dictionary of expected row results.  That proved that all the rows are present in the database. 

We Bundled The Tests In Our App And Ask The End User To Run Them On His Machine

Our installation instructions ask the end user to import the Example CRFs and Domains into his database and then run the tests to provide confidence that the database contains the expected results prior to relying on them as a source of truth for the Example CRFs and Domains in the CDASH Implementation Guide.

Achieving Atomic, Consistent, Isolated & Durable Results

According to Wikipedia:

In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties of database transactions intended to guarantee data validity despite errors, power failures, and other mishaps.[1] In the context of databases, a sequence of database operations that satisfies the ACID properties (which can be perceived as a single logical operation on the data) is called a transaction. For example, a transfer of funds from one bank account to another, even involving multiple changes such as debiting one account and crediting another, is a single transaction (a.k.a atomicity).

Handling Transactions

We selected third-party software capable of importing all the rows in a Worsheet as a single transaction and rolling back the transaction if an error occurs. 

 

We simulated the failure of the database as we attempted to import the AE Example CRF as follows:

  • We deleted the AE Example CRF Worksheet from the Database using the "Delete CRF" menu option.

  • We opened SQL Server Management Studio (SSMS) and displayed the Example CRF database table.  We browsed the list of Example CRFs in the table and confirmed that the AE Example CRF was not in the database table.

  • We manually added code to the database repository responsible for importing the AE Example CRF into the database.  The code tests to see if it trying to insert the 11th row.  If so, the code introduces an error which causes the transaction to fail and attempt to rollback the 10 rows that were previously imported into the database. 

  • To confirm this, we switched back to SSMS broswed the list Example CRFs again. As expected, the AE Example CRF was not there.

Consistency Property

Consistency is a very general term, which demands that the data must meet all database validation rules. The App confirms that each column in each row in the Worksheet passes validation checks before attempting to insert Worksheet into the database.  Therefore, the database does not contain any database validation rules because none are needed. 

Isolation Property

According to Wikipedia, to achieve isolation, we assume two transactions execute at the same time, each attempting to modify the same data. One of the two must wait until the other completes in order to maintain isolation.

As a reminder, we did not see a need to design the application so that two different end users in the same company need to modify the data in the CasahIgMetadata database at the same time.  So, please do not do that.

Durability Property

TDB

Application Setup Tests
  • The Database Connection String test allows the end user to confirm that he configured the application correctly before he tries to import a Worksheet

  • The Internet Connection test allows the end user to confirm that he has an Internet connection before importing a Worksheet.  An Internet connection is required so the App can send an email to GalaxyeClinical if it encounters an error.

bottom of page