CRUD operation verification in Testing Fundamentals - Framework Patterns

Framework Mode - CRUD operation verification

Folder Structure

crud-verification-project/
├── tests/
│   ├── create_tests.py
│   ├── read_tests.py
│   ├── update_tests.py
│   └── delete_tests.py
├── pages/
│   └── resource_page.py
├── utils/
│   ├── api_client.py
│   └── helpers.py
├── config/
│   └── config.yaml
├── reports/
│   └── test_report.html
└── conftest.py
  

Test Framework Layers

• Test Layer: Contains test scripts for each CRUD operation (Create, Read, Update, Delete). Each test verifies the expected behavior of the operation.
• Page/Object Layer: Represents the resource or entity being tested. Provides methods to perform CRUD actions in a reusable way.
• Utility Layer: Contains helper functions and API client code to interact with the system under test, such as sending HTTP requests or database queries.
• Configuration Layer: Holds environment settings, credentials, and other configurable parameters to run tests in different setups.

Configuration Patterns

Use a config.yaml file to store environment URLs, credentials, and other settings. Load this config in tests and utilities to avoid hardcoding values.

Example config.yaml content:

environment:
  base_url: "https://api.example.com"
  username: "testuser"
  password: "securepass"
browser: "chrome"
  

Use fixtures (e.g., in conftest.py) to initialize test setup like authentication tokens or database connections before tests run.

Test Reporting and CI/CD Integration

• Generate HTML or XML test reports after test runs to summarize passed and failed CRUD tests.
• Integrate the test suite with a CI/CD pipeline (e.g., GitHub Actions, Jenkins) to run tests automatically on code changes.
• Use clear test names and logs to quickly identify which CRUD operation failed and why.

Framework Design Principles

1. Single Responsibility: Separate tests by CRUD operation for clarity and easier maintenance.
2. Reusable Components: Use page or resource objects to avoid repeating code for CRUD actions.
3. Data-Driven Testing: Use test data inputs to cover different scenarios for each CRUD operation.
4. Clear Assertions: Verify both the action success and the data integrity after each CRUD operation.
5. Environment Independence: Use configuration files and fixtures to run tests in different environments without code changes.

Self Check

Question: Where in this folder structure would you add a new test script to verify the "Update" operation for a new resource type?

Key Result

Organize CRUD tests by operation with reusable resource objects and clear configuration for maintainable verification.

Practice

1. Which CRUD operation is responsible for adding new data to a system?

easy

A. Delete

B. Read

C. Update

D. Create

Solution

1. Step 1: Understand CRUD operations

   CRUD stands for Create, Read, Update, and Delete, each representing a basic data operation.

2. Step 2: Identify the operation for adding data

   The 'Create' operation is used to add new data entries into the system.

3. Final Answer:

   Create -> Option D

4. Quick Check:

   Adding new data = Create [OK]

Hint: Create means add new data to the system [OK]

Common Mistakes:

• Confusing 'Create' with 'Update'
• Thinking 'Read' adds data
• Mixing 'Delete' with adding data

2. Which of the following is the correct syntax to verify a Delete operation in a test case?

easy

A. assert data.exists() == True

B. assert data.is_deleted() == True

C. assert data.count() > 0

D. assert data.is_present() == True

Solution

1. Step 1: Understand Delete verification

   To verify deletion, the test must confirm the data no longer exists or is marked deleted.

2. Step 2: Choose assertion that confirms deletion

   assert data.is_deleted() == True correctly checks that the data was deleted.

3. Final Answer:

   assert data.is_deleted() == True -> Option B

4. Quick Check:

   Delete check uses is_deleted() == True [OK]

Hint: Check deletion with is_deleted() == True [OK]

Common Mistakes:

• Using exists() == True after deletion
• Checking count() > 0 which means data exists
• Confusing is_present() with deletion status

3. Consider this test code snippet verifying an Update operation:

original_value = record.get('name')
record.update({'name': 'Alice'})
updated_value = record.get('name')
assert updated_value == 'Alice'

What will be the result of this test if the update works correctly?

medium

A. Test passes because updated_value matches 'Alice'

B. Test fails because original_value is not checked

C. Test fails due to syntax error in update method

D. Test passes but updated_value remains original_value

Solution

1. Step 1: Analyze the update operation

   The code updates the 'name' field to 'Alice' and retrieves it again.

2. Step 2: Check the assertion logic

   The assertion checks if updated_value equals 'Alice', which should be true if update works.

3. Final Answer:

   Test passes because updated_value matches 'Alice' -> Option A

4. Quick Check:

   Updated value == 'Alice' means test passes [OK]

Hint: Assert updated value equals new data after update [OK]

Common Mistakes:

• Assuming original_value must be checked in this test
• Thinking update method has syntax error
• Believing updated_value stays unchanged after update

4. A tester wrote this code to verify a Create operation:

new_record = db.create({'id': 1, 'value': 100})
assert new_record.id == 1
assert new_record.value == 100
assert db.find(1) == None

What is the error in this test?

medium

A. The assertion db.find(1) == None is incorrect after creation

B. The new_record object does not have id attribute

C. The create method should not return a record

D. The value 100 is not valid for creation

Solution

1. Step 1: Understand Create operation verification

   After creating a record, it should be found in the database.

2. Step 2: Analyze the assertion db.find(1) == None

   This assertion expects no record found, which contradicts the creation.

3. Final Answer:

   The assertion db.find(1) == None is incorrect after creation -> Option A

4. Quick Check:

   Created record must be found, so find(1) != None [OK]

Hint: After create, find should return the record, not None [OK]

Common Mistakes:

• Expecting find to return None after creation
• Assuming create returns nothing
• Confusing attribute existence on new_record

5. You want to verify all CRUD operations on a user profile. Which sequence of test steps is best to ensure data integrity?

hard

A. Create user, Update user, Delete user, Read user

B. Read user, Create user, Update user, Delete user

C. Create user, Read user, Update user, Delete user

D. Delete user, Create user, Read user, Update user

Solution

1. Step 1: Understand logical CRUD test order

   First, create data to have something to work with, then read to verify creation.

2. Step 2: Follow with update and delete

   Update tests changes, and delete confirms removal, maintaining data integrity.

3. Final Answer:

   Create user, Read user, Update user, Delete user -> Option C

4. Quick Check:

   CRUD order: Create, Read, Update, Delete [OK]

Hint: Test CRUD in order: Create, Read, Update, Delete [OK]

Common Mistakes:

• Deleting before creating data
• Reading before data exists
• Updating before creation