What is a State Test?
A State-based test is a regression test that begins at a seeded state of a feature. This then allows testers to test specific instances of your app and reach later portions of longer and more complex workflows while maintaining tests at a manageable length.
Defining Characteristics of the State Test:
- Dedicated Resources - While these tests can be enormously useful, they may require a significant amount of developer resources to set up and maintain.
- Strategically Designed - It's not advisable to commit resources to cover every possible state of a feature. It's more often than not that many states will share the same backend logic. It is best to work out with your developers what independent backend pieces are shared to determine where coverage can be best provided.
- Synchronized with Feature Lifecycle - The above characteristics of state tests make it important to consider the stage of the feature's lifecycle. With some exceptions state-tests are suited to features that are generally more mature and stable.
When should I run my State Tests?
State tests are generally deployed after a feature has been productized and moved into General Availability. They should be run before every major release.
Why are State Tests important?
Though Rainforest regression tests can be written to cover even the most complex series' of actions an end-user could follow, more complex regressions can grow to an unwieldy length very quickly. In these situations the State test allows you to balance the coverage needed for complex flows with the desire for shorter tests that can be practically managed.
While there is a definite cost to creating seeded states, there is a significant ROI as well. State tests allow you to speed up test creation by shortening the amount of time required to write actual steps. Additionally, the compression of early steps into a seeded state could translate into shorter tests as a whole, which in turn allows tests to be run more quickly and with more confidence in the results.