ABT Foundations • Module 2
The Philosophy of ABT
Understanding the mindset behind effective test automation
Module 2 of 30
Guest Lecturer: A Software Architect
"Good architecture is not about making decisions; it's about deferring decisions until you have enough information."
"Dear Marilyn,
My team keeps arguing about whether to use Page Object Model or some other pattern. We've rewritten our test framework three times in two years. How do we stop this cycle?
— Frustrated Framework Hopper"
Marilyn Responds:
The problem isn't which pattern you choose—it's that you're choosing patterns before understanding principles. Patterns are solutions to specific problems. If you don't understand the problem, you'll misapply the solution.
Action-Based Testing isn't a pattern; it's a philosophy. It says: separate what you're testing from how you're testing it. Once you internalize this principle, the right patterns emerge naturally.
Stop debating frameworks. Start understanding the problem you're solving.
The Three Separations
ABT enforces three critical separations:
- Test Logic from Test Data — What you're testing vs. what values you're using
- Business Actions from Technical Implementation — What the user does vs. how it's done
- Test Definition from Test Execution — What should happen vs. when/where it runs
Quick Check: Module 2
Question: Which separation is NOT part of the ABT philosophy?
a) Test logic from test data
b) Business actions from technical implementation
c) Test code from production code
d) Test definition from test execution
(Answer: c — While keeping test code separate from production code is good practice, it's not one of ABT's three core separations.)