Testability Tips
1. A Balm for Programmers
What it means:
Designing systems using finite state machines (FSMs) makes them easier to test. That’s the key idea.
Why it helps:
• FSMs have defined states and transitions, so the behavior is predictable.
• When behavior is clear, test cases can be written easily.
Example:
Imagine a fan with 3 modes: Off, Low, High. Each button press moves it from one state to another:
• Off → Low → High → Off
This simple state machine is easy to test by simulating button presses.
2. How Big, How Small
What it means:
As the number of finite state machines increases, the number of possible combinations of their
behaviors explodes — and most of them are bad or untestable.
Number of FSMs Good/Bad combinations
2 FSMs 8
3 FSMs 80
4 FSMs 2700 (mostly bad)
5 FSMs 275,000 (mostly bad)
6 FSMs 100 million (mostly bad)
Why it matters:
• More machines = more complexity = more chances of bad design.
• Testability becomes very difficult if not planned properly.
Tip:
Keep FSM designs simple and clean for better testability.
3. Switches, Flags, and Unachievable Paths
Key Ideas:
• Switches and Flags are used to control the flow in FSMs.
• They help guide which path (or state transition) the software takes.
• Often used with True/False conditions (like Boolean variables).
Example:
Let’s say you have a switch loggedIn = true.
• If true, go to Dashboard state.
• If false, stay in Login state.
Unachievable Path:
• Sometimes, due to bad design, certain paths (states) can never be reached. These are
unachievable paths and indicate poor FSM design.
Tip:
Make sure all paths can be reached through proper flag/switch combinations.
4. Essential and Inessential Finite State Behavior
What it means:
Not all state behaviors are equally important. Some are essential (affect outcomes), and some are
inessential (do not matter much for overall logic).
Also, we compare FSMs with combinational machines:
• FSMs: Behavior depends on past states.
• Combinational Machines: Behavior depends only on current inputs (like logic gates in
hardware).
Example:
• In a FSM: Pressing “Pay” after “Add to Cart” works.
• In a combinational machine: Pressing “Pay” without history may still compute some value, but
doesn’t consider previous states.
Predicate Values:
• These are conditions (like isLoggedIn == true) that determine the path.
• In combinational machines, once these values are known, the path is fixed and doesn’t
change.
Conclusion:
FSMs require understanding state transitions, while combinational machines are simpler but less
useful for software with sequence-based behavior.
5. Follow Design Guidelines
To improve testability, follow these FSM design rules:
Guidelines:
1. Learn FSM usage in both hardware and software.
2. Design abstract machines that meet the user’s needs.
3. Make the FSM explicit — show all states and transitions clearly.
4. Test early with prototypes — check how much time and memory the design needs.
Example:
Create a mock version of a login system FSM:
• States: Start → Entered Username → Entered Password → Success or Failure
• Prototype this FSM to ensure all transitions happen as expected.
Summary Table
Section Key Tip Example
A balm for programmers Use FSMs for easier testing Fan with 3 modes
How big how small Keep FSM count low Too many machines = complexity
Switches & Flags Control flow with true/false loggedIn = true
Essential Behavior Focus on important transitions Login → Dashboard vs. color theme
Design Guidelines Build clear, testable FSMs Prototyped login FSM
