Module 7 of 10
Building Test Modules
A test module is not just a container for tests—it is a living document that captures your understanding of the system. Let us build one from scratch, step by logical step.
Dear Marilyn: I understand the theory of ABT, but when I sit down to create a test module, I do not know where to start. What goes first? The actions? The test cases? The data?
— Blank Page in Boston
Dear Blank Page: The blank page is intimidating only because you are thinking of all the pieces at once. A test module is built like a house: foundation first, then walls, then roof. Let me walk you through the construction process.
Step 1: Define the Test Objective
Before writing a single action, answer this question: What are we trying to verify? The test objective is the "why" behind your test module.
Example: Invoice Test Module
# Test Objective
Verify that the Invoice Management system correctly handles
the complete invoice lifecycle: creation, modification,
approval, and archival. Ensure calculations are accurate
and audit trails are maintained.
Good Objectives
- • Specific and measurable
- • Focused on business value
- • Scoped to one business object
Bad Objectives
- • "Test everything"
- • "Make sure it works"
- • Too broad or vague
Step 2: Identify the Actions
Now ask: What operations can a user perform on this business object?List them without worrying about implementation. These become your high-level actions.
Invoice Actions Inventory
CRUD Operations
- create_invoice
- view_invoice
- edit_invoice
- delete_invoice
Business Operations
- submit_for_approval
- approve_invoice
- reject_invoice
- archive_invoice
Line Item Operations
- add_line_item
- remove_line_item
- update_line_quantity
Verification Actions
- check_invoice_total
- check_invoice_status
- check_audit_trail
Naming Convention Reminder
Always use verb_noun format: create_invoice, not invoice_create. The action should read like a command.
Step 3: Define the Checks
Checks are the verification points in your test. They answer: How do we know the action succeeded? In ABT, checks are explicit actions, not hidden assertions buried in code.
Types of Checks
Value Checks
Verify that a field contains an expected value.
check_invoice_total(expected: "$1,250.00")State Checks
Verify that the system is in an expected state.
check_invoice_status(expected: "Pending Approval")Existence Checks
Verify that something exists (or does not exist).
check_invoice_exists(invoice_id: "INV-2024-001")Error Checks
Verify that an expected error message appears.
check_error_message(expected: "Invoice total cannot be negative")Step 4: Design the Data Sets
Data-driven testing separates the "what" from the "with what." Instead of writing ten tests that differ only in input values, write one test and feed it ten data rows.
Invoice Test Data Set
| Scenario | Customer | Amount | Tax Rate | Expected Total |
|---|---|---|---|---|
| Standard | Acme Corp | $1,000.00 | 10% | $1,100.00 |
| Tax Exempt | Government Agency | $5,000.00 | 0% | $5,000.00 |
| High Value | Enterprise Inc | $100,000.00 | 8.5% | $108,500.00 |
| Minimum | Small Biz LLC | $0.01 | 10% | $0.01 |
Notice how each row represents a different scenario, not just random data. Good test data is designed to exercise specific conditions: boundary values, special cases, and business rules.
Step 5: Write the Test Cases
Now we assemble the pieces. A test case is a sequence of actions that tells a story: setup, action, verification.
Test Case: Create and Approve Invoice
# Test Case: TC-INV-001
# Objective: Verify complete invoice workflow
# Data Set: Row 1 (Standard)
# Setup
login_as_user(role: "Invoice Clerk")
navigate_to(page: "Invoice Management")
# Create Invoice
create_invoice(customer: [Customer], amount: [Amount])
add_line_item(description: "Consulting Services", quantity: 1, price: [Amount])
check_invoice_total(expected: [Expected Total])
# Submit for Approval
submit_for_approval()
check_invoice_status(expected: "Pending Approval")
# Approve (as Manager)
login_as_user(role: "Manager")
approve_invoice()
check_invoice_status(expected: "Approved")
check_audit_trail(contains: "Approved by Manager")
Notice the Pattern
The test reads like a user story. Anyone can understand what it does without knowing the implementation details. The [brackets]indicate data-driven values that will be substituted from the data set.
Advanced: Decision Tables
Dear Marilyn: My business rules have many conditions that interact with each other. How do I organize tests when "if A and B but not C, then do X unless D" is the norm?
— Conditional in California
Dear Conditional: You need a Decision Table. This technique maps all possible combinations of conditions to their expected outcomes. It ensures you do not miss any combination—and it makes the logic visible to everyone.
Example: Order Processing Decision Table
Consider an order system where the action depends on: Is the dialog data correct? Is it a large order? Is the customer an online customer?
| Conditions | Case 1 | Case 2 | Case 3 | Case 4 | Case 5 | Case 6 |
|---|---|---|---|---|---|---|
| Dialog data correct? | Y | Y | Y | Y | N | N |
| Large order? | Y | Y | N | N | — | — |
| Online customer? | Y | N | Y | N | — | — |
| Expected Action | Priority Processing | Manager Review | Auto Process | Standard Process | Show Error | Show Error |
Benefits of Decision Tables
- Forces complete coverage of all condition combinations
- Makes business logic visible and reviewable
- Each column becomes a test case
- Easy to spot missing or contradictory rules
When to Use Decision Tables
- Multiple conditions affect the outcome
- Business rules are complex or frequently change
- You need to verify all edge cases
- Stakeholders need to review test coverage
Module Summary
- Start with a clear test objective that defines what you are verifying.
- Identify all actions (CRUD + business operations) before writing tests.
- Make checks explicit—they are actions, not hidden assertions.
- Design data sets around scenarios, not random values.
- Test cases should read like user stories: setup, action, verification.
- Decision Tables map condition combinations to outcomes for complex business rules.