This post is part of the Pride & Paradev series.
A test controller is a way to directly access functionality in your web application without following the standard web application flow: for example, you may want to directly access the credit card details screen, so what you do is develop a ‘credit card details controller’ which sets the desired state (an order and a customer) and shows the credit card details screen to you.
The test controller is hit via a test URL which sets the state and redirects to the appropriate page. These test controllers are either not deployed to production, or are disallowed via routing in production.
So, should you use test controllers for testing?
You should use test controllers for testing
Test controllers make for very efficient and easy to read automated acceptance tests. Instead of something like:
Given I am on the home page When I add some products to my basket And I provide my customer details And I select express shipping Then I should see the customer details screen When I submit an invalid credit card number Then I should see an error And the credit card details are empty and need to be reentered
This can simply become:
Given I am on the credit card details page When I submit an invalid credit card number Then I should see an error And the credit card details are empty and need to be reentered
The Given step simply calls the test controller that sets up required state and provides the screen. The scenario is focused on testing one thing and isn’t reliant on a process flow to set up the state.
Test Controllers also allow you to test something before other things are developed. For example, in the above case you could test the credit card details screen even though the shipping selection page was not developed. As long as the controller sets things up correctly, it allows you to test stories in isolation without having dependencies on other user stories, which results in faster velocity.
You shouldn’t use test controllers for testing
Test Controllers set up state in your web application, which may be different to the state set up by using the application itself. For example, a test controller for credit card details may set the shipping method, but it may set it differently to how the shipping method screen does it, which results in inconsistent behavior in your application, and potentially false positives. This leads to failures where you are not sure whether there is an bug in your application, or just in the test controller itself.
User’s don’t use test controllers so neither should you. It may be convenient to jump into testing a certain page but testing is as much about the journey as the destination, so jumping straight in may mean you miss important bugs along the way.