Grad.Codebook.Testing 2.1.1

Grad.Codebook.Testing

Testing utilities for Grad Codebook. This package allows projects that depend on Codebook to test functionality that requires database access.

Purpose

The Grad.Codebook package exposes data through database views that query from the EDW (Enterprise Data Warehouse). For testing purposes, projects need a way to set up a test database without depending on the EDW. This package provides that capability by creating EDW schema tables (edw.t_*) and populating them with test data, then creating views (dbo.*) that match the production schema. This approach ensures that test data behaves exactly like production data and prevents drift between mock tables and real views.

Usage

using Grad.Codebook.Testing;

// Create an instance with your test database connection string
var testDb = new CodebookTestDatabase(connectionString);

// Set up the database (creates tables and inserts test data)
testDb.Setup();

// Or use async version
await testDb.SetupAsync();

Test Data Constants

Instead of using magic strings in your tests, use the TestData class to access test data objects with all their properties:

using Grad.Codebook.Testing;

// Access test data as full objects with properties
var csProgram = TestData.GradPrograms.ComputerScienceMS;
Assert.Equal("10KS0112MS", csProgram.ProgramCode);
Assert.Equal("Computer Science", csProgram.MajorTitle);

// Use department codes
var csDepartment = TestData.Departments.ComputerScience;
Assert.Equal("434", csDepartment.DepartmentCode);
Assert.Equal("Department of Computer Science", csDepartment.FullName);

// Access all types of test data
var engineering = TestData.Colleges.Engineering;
var phdDegree = TestData.Degrees.PhD;
var mathMinor = TestData.Minors.Mathematics;
var csSubject = TestData.Subjects.ComputerScience;

Available test data categories:

• TestData.Colleges - Test colleges
• TestData.Departments - Test departments
• TestData.Degrees - Test degrees
• TestData.GradPrograms - Test graduate programs
• TestData.Minors - Test minors
• TestData.Majors - Test majors
• TestData.Subcolleges - Test subcolleges
• TestData.Subjects - Test subjects
• TestData.Concentrations - Test concentrations
• TestData.Curriculums - Test curriculums

What it Does

The CodebookTestDatabase class:

1. Creates the Codebook database if it doesn't exist
2. Creates the edw schema if it doesn't exist
3. Drops existing views and tables if they exist (to ensure a clean state)
4. Creates edw schema tables that match the EDW structure:
   • edw.t_coll (colleges)
   • edw.t_dept (departments)
   • edw.t_conc (concentrations)
   • edw.t_curr (curriculums)
   • edw.t_deg (degrees)
   • edw.t_school_sub_coll (subcolleges)
   • edw.t_subj (subjects)
   • edw.t_pgm (programs)
   • edw.t_minor (minors)
   • edw.t_major (majors)
   • edw.t_joint_pgm (joint programs)
   • edw.t_pgm_joint_pgm (program-joint program mapping)
   • edw.t_pgm_major (program-major mapping)
   • edw.t_conc_pgm_major (concentration-program-major mapping)
   • edw.t_pgm_rule_conc (program rule concentrations)
   • edw.t_pgm_deg_title (program degree titles)
5. Inserts test data into the edw tables
6. Creates dbo views using DatabaseMigrator, which runs the same migrations used in production:
   • colleges
   • departments
   • concentrations
   • curriculums
   • degrees
   • subcolleges
   • subjects
   • grad_programs
   • minors
   • majors
   • joint_programs
   • major_concentrations
   • program_concentrations
   • department_names
   • program_names

Test Data

The package includes sample data for:

• 3 colleges (Engineering, Liberal Arts & Sciences, Graduate College)
• 3 departments (Computer Science, Mathematics, ECE)
• 4 graduate programs (CS MS, CS PhD, Math MS, Math PhD)
• 2 minors (CS, Math)
• 2 majors (CS, Math)
• 2 concentrations (AI, Database Systems)
• And corresponding relationships between these entities

Notes

This approach mirrors the production database structure by:

• Using the same edw schema tables as production
• Using DatabaseMigrator to create views with the same migrations used in production
• Ensuring test data behaves identically to production data
• Preventing drift between test and production schemas

While it's not ideal for dependent projects to use the database directly, this approach is necessary for scenarios involving complex joins that aren't feasible with API calls.