Data validation rules in Testing Fundamentals - Framework Patterns

Framework Mode - Data validation rules

Folder Structure

  data-validation-framework/
  ├── config/
  │   ├── environments.json       # Environment-specific settings
  │   └── validation-rules.json   # Centralized data validation rules
  ├── src/
  │   ├── validators/             # Validation logic modules
  │   │   ├── emailValidator.js
  │   │   ├── phoneValidator.js
  │   │   └── dateValidator.js
  │   ├── utils/                  # Helper functions
  │   │   └── formatters.js
  │   └── dataLoaders/            # Data input and parsing
  │       └── csvLoader.js
  ├── tests/                      # Test cases for validation rules
  │   ├── emailValidation.test.js
  │   ├── phoneValidation.test.js
  │   └── dateValidation.test.js
  ├── reports/                    # Test execution reports
  ├── package.json                # Project dependencies and scripts
  └── README.md
  

Test Framework Layers

• Config Layer: Holds environment settings and validation rules in JSON files for easy updates.
• Validator Layer: Contains reusable validation functions for different data types (email, phone, date).
• Data Loader Layer: Responsible for loading and parsing input data from files or sources.
• Test Layer: Automated test scripts that apply validation rules to sample or real data and assert correctness.
• Utility Layer: Helper functions for formatting, logging, or common operations used by validators and tests.

Configuration Patterns

• Centralized Rules: Store all validation rules in validation-rules.json for easy maintenance and updates without code changes.
• Environment Settings: Use environments.json to define different data sources or parameters per environment (dev, test, prod).
• Parameterization: Tests read config files at runtime to adapt validation logic dynamically.
• Secrets Management: Keep sensitive data like credentials out of validation rules; use environment variables or secure vaults.

Test Reporting and CI/CD Integration

• Use test runners (e.g., Jest, Mocha) that generate clear pass/fail reports with details on which validation rules failed.
• Integrate with CI/CD pipelines (GitHub Actions, Jenkins) to run validation tests automatically on code changes.
• Generate HTML or JSON reports stored in reports/ folder for easy review by team members.
• Set alerts or notifications on validation failures to quickly fix data issues.

Best Practices for Data Validation Rules Framework

• Single Source of Truth: Keep validation rules centralized to avoid duplication and inconsistencies.
• Reusable Validators: Write small, focused validation functions that can be combined or reused across tests.
• Clear Error Messages: Validation failures should provide descriptive messages to help identify data issues quickly.
• Automate Early: Run validation tests early in the data pipeline to catch errors before they propagate.
• Version Control: Track changes to validation rules and tests in source control for audit and rollback.

Self Check

Where in this framework structure would you add a new validator for checking postal codes?

Key Result

Centralize validation rules and use reusable validator functions tested automatically with clear reporting.

Practice

1. What is the main purpose of data validation rules in software testing?

easy

A. To check if input data is correct and useful

B. To improve the speed of the software

C. To change the data format automatically

D. To delete old data from the system

Solution

1. Step 1: Understand the role of data validation

   Data validation rules are designed to check input data for correctness and usefulness before processing.

2. Step 2: Compare options with the definition

   Only To check if input data is correct and useful correctly states this purpose; others describe unrelated tasks.

3. Final Answer:

   To check if input data is correct and useful -> Option A

4. Quick Check:

   Data validation = Check correctness [OK]

Hint: Validation means checking data correctness early [OK]

Common Mistakes:

• Confusing validation with data transformation
• Thinking validation improves software speed
• Assuming validation deletes data

2. Which of the following is a correct example of a data validation rule for an email field?

easy

A. The field must contain only numbers

B. The field must not be empty and must contain '@' symbol

C. The field must be exactly 5 characters long

D. The field must be left blank

Solution

1. Step 1: Identify common email validation rules

   Email fields require non-empty input and must include '@' to be valid.

2. Step 2: Evaluate each option

   The field must not be empty and must contain '@' symbol matches these rules; A, B, and D do not fit email validation.

3. Final Answer:

   The field must not be empty and must contain '@' symbol -> Option B

4. Quick Check:

   Email validation = Non-empty + '@' [OK]

Hint: Emails always need '@' and something before/after [OK]

Common Mistakes:

• Checking length without '@' for emails
• Allowing empty email fields
• Restricting emails to numbers only

3. Consider this validation rule in a test script:

assert age >= 18 and age <= 65

What will happen if age = 70 during test execution?

medium

A. Test will ignore the age value

B. Test will pass because 70 is a valid age

C. Test will raise a syntax error

D. Test will fail because 70 is outside the valid range

Solution

1. Step 1: Understand the validation condition

   The rule requires age to be between 18 and 65 inclusive.

2. Step 2: Check the given age value

   Age 70 is greater than 65, so the condition fails and assertion fails.

3. Final Answer:

   Test will fail because 70 is outside the valid range -> Option D

4. Quick Check:

   Age 70 > 65 = Fail [OK]

Hint: Check if value fits the range in assertion [OK]

Common Mistakes:

• Assuming test passes if value is above max
• Confusing syntax error with assertion failure
• Ignoring assertion conditions

4. A tester wrote this validation rule:

assert len(username) > 0 and len(username) < 15

What is the problem with this rule if the username length is exactly 15?

medium

A. The test will fail because 15 is not less than 15

B. The test will pass because 15 is allowed

C. The test will cause a runtime error

D. The test will ignore the username length

Solution

1. Step 1: Analyze the length condition

   The rule requires username length to be greater than 0 and less than 15.

2. Step 2: Check the boundary value 15

   Length 15 is not less than 15, so assertion fails.

3. Final Answer:

   The test will fail because 15 is not less than 15 -> Option A

4. Quick Check:

   Length 15 < 15? No = Fail [OK]

Hint: Check if boundary values are included or excluded [OK]

Common Mistakes:

• Assuming less than includes the number itself
• Ignoring boundary conditions
• Thinking test causes error instead of fail

5. You need to validate a form field that accepts only positive integers less than 1000 and not empty. Which combined validation rule is correct?

hard

A. assert value.isalpha() and int(value) > 0

B. assert value != '' and int(value) >= 1000

C. assert value.isdigit() and 0 < int(value) < 1000

D. assert value == '' or int(value) < 0

Solution

1. Step 1: Understand the requirements

   Value must be non-empty, only digits, positive, and less than 1000.

2. Step 2: Evaluate each option

   assert value.isdigit() and 0 < int(value) < 1000 checks digits only, converts to int, and tests range correctly. Others fail one or more conditions.

3. Final Answer:

   assert value.isdigit() and 0 < int(value) < 1000 -> Option C

4. Quick Check:

   Digits + positive + <1000 = assert value.isdigit() and 0 < int(value) < 1000 [OK]

Hint: Check digits, non-empty, and range in one assertion [OK]

Common Mistakes:

• Using isalpha() instead of isdigit()
• Allowing empty strings
• Checking wrong numeric ranges