Stored procedure testing in Testing Fundamentals - Framework Patterns

Framework Mode - Stored procedure testing

Folder Structure

stored-procedure-testing/
├── tests/
│   ├── test_procedures.sql       -- SQL scripts to test stored procedures
│   ├── test_data.sql             -- Setup test data
│   └── cleanup.sql               -- Cleanup test data
├── procedures/
│   └── my_procedure.sql          -- Stored procedure source code
├── config/
│   └── db_config.json            -- Database connection settings
├── utils/
│   └── db_helper.py              -- Helper scripts for DB connection and query execution
└── reports/
    └── test_report.html          -- Test execution reports
  

Test Framework Layers

• Database Layer: Contains stored procedures and test data scripts.
• Test Scripts Layer: SQL scripts that call stored procedures with test cases and verify outputs.
• Utility Layer: Helper scripts (e.g., Python) to connect to the database, run SQL scripts, and fetch results.
• Configuration Layer: Holds database connection details and environment settings.
• Reporting Layer: Generates readable test reports from test execution results.

Configuration Patterns

• Use a db_config.json file to store database host, port, username, password, and database name.
• Support multiple environments (dev, test, prod) by having separate config sections or files.
• Use environment variables or secure vaults to keep credentials safe and avoid hardcoding.
• Allow test runner scripts to read config dynamically to connect to the correct database.

Test Reporting and CI/CD Integration

• Generate HTML or XML reports summarizing which stored procedure tests passed or failed.
• Include details like input parameters, expected vs actual results, and error messages.
• Integrate test execution into CI/CD pipelines to run tests automatically on code changes.
• Fail the build if critical stored procedure tests fail to prevent faulty database code deployment.

Best Practices

• Isolate test data: Prepare and clean up test data before and after each test to avoid side effects.
• Use assertions on stored procedure outputs to verify correctness.
• Test edge cases and error handling inside stored procedures.
• Keep test scripts simple and readable, focusing on one scenario per test.
• Automate tests to run frequently and catch regressions early.

Self Check

Where in this folder structure would you add a new test script to verify a recently added stored procedure?

Key Result

Organize stored procedure tests with clear layers: SQL test scripts, utilities for DB access, config for environments, and reporting for results.

Practice

1. What is the main purpose of testing a stored procedure in a database?

easy

A. To verify that the procedure performs the expected operations correctly

B. To create new tables in the database

C. To delete all data from the database

D. To change the database schema automatically

Solution

1. Step 1: Understand stored procedure testing goal

   Testing stored procedures means checking if they do what they are supposed to do.

2. Step 2: Identify correct purpose

   Creating tables, deleting data, or changing schema are not testing goals but database operations.

3. Final Answer:

   To verify that the procedure performs the expected operations correctly -> Option A

4. Quick Check:

   Testing = Verify expected operations [OK]

Hint: Testing checks if procedure works as expected [OK]

Common Mistakes:

• Confusing testing with creating or deleting data
• Thinking testing changes database structure
• Assuming testing runs automatically without checks

2. Which SQL command is used to execute a stored procedure named GetUserData with an input parameter userId?

easy

A. EXECUTE GetUserData userId;

B. RUN PROCEDURE GetUserData userId;

C. START GetUserData(userId);

D. CALL GetUserData(userId);

Solution

1. Step 1: Recall correct syntax for calling stored procedures

   The standard SQL command to run a stored procedure is CALL procedure_name(parameters);

2. Step 2: Match syntax with options

   Only CALL GetUserData(userId); uses CALL with parentheses and parameter correctly.

3. Final Answer:

   CALL GetUserData(userId); -> Option D

4. Quick Check:

   CALL + procedure + (params) = correct call [OK]

Hint: Use CALL with parentheses to run procedures [OK]

Common Mistakes:

• Using EXECUTE without parentheses
• Using RUN PROCEDURE which is invalid syntax
• Forgetting parentheses around parameters

3. Consider this stored procedure call:
CALL CalculateDiscount(100, 0.1);
If the procedure returns the discounted price by subtracting the discount (price * rate), what is the expected output?

medium

A. 10

B. 110

C. 90

D. 100

Solution

1. Step 1: Understand inputs and calculation

   Price is 100, discount rate is 0.1 (10%). Discount amount = 100 * 0.1 = 10.

2. Step 2: Calculate discounted price

   Discounted price = 100 - 10 = 90.

3. Final Answer:

   90 -> Option C

4. Quick Check:

   100 - (100*0.1) = 90 [OK]

Hint: Subtract price * rate from price for discount [OK]

Common Mistakes:

• Adding instead of subtracting discount
• Using discount rate as final price
• Confusing discount amount with discounted price

4. You have this stored procedure call:
CALL UpdateUserEmail(123, '[e-mail]');
But it returns an error: ERROR: procedure UpdateUserEmail does not exist.
What is the most likely cause?

medium

A. The procedure name is misspelled or does not exist

B. The email format is invalid

C. The user ID 123 does not exist

D. The database connection is lost

Solution

1. Step 1: Analyze error message

   The error says the procedure does not exist, which means the database cannot find a procedure named UpdateUserEmail.

2. Step 2: Identify likely cause

   This usually happens if the procedure name is wrong or it was not created.

3. Final Answer:

   The procedure name is misspelled or does not exist -> Option A

4. Quick Check:

   Error about procedure existence = name or creation issue [OK]

Hint: Check procedure name spelling and existence first [OK]

Common Mistakes:

• Assuming input data causes procedure not found error
• Blaming connection issues without checking procedure
• Ignoring error message details

5. You want to test a stored procedure CalculateTax that takes an income amount and returns tax owed.
The procedure has a bug: it returns NULL for zero income instead of 0.
Which test case will best detect this bug?

hard

A. Call CalculateTax(1000) and check if result is positive

B. Call CalculateTax(0) and check if result is 0

C. Call CalculateTax(-100) and check for error

D. Call CalculateTax(NULL) and check for NULL

Solution

1. Step 1: Understand the bug

   The procedure returns NULL instead of 0 when income is zero.

2. Step 2: Choose test case to detect bug

   Testing with zero income and expecting 0 will reveal if NULL is returned incorrectly.

3. Final Answer:

   Call CalculateTax(0) and check if result is 0 -> Option B

4. Quick Check:

   Test zero input to catch NULL instead of 0 bug [OK]

Hint: Test edge inputs like zero to find null bugs [OK]

Common Mistakes:

• Testing only positive values misses zero case
• Testing negative income when not required
• Assuming NULL input tests zero income bug