About front-end testing
I was asked many times about front-end testing: what to test and how to test it, and what tool are best to be used?
And this is my final answer:
You need to consider Mike Cohn’s analogy – the test pyramid. It will help you decide what kind of testing best to be done in a certain situation.
At the bottom of the pyramid are the solid test units they are the foundation of the test strategy – they can provide you with a fast feedback.
At the top, occupying the smallest part of the pyramid , are the UI tests. They interact with your UI directly(for example Selenium), but are costly and very slow on feedback. They can become very brittle and hard to maintain.
At the middle of the pyramid there are integration tests that do not require an UI. In Rails, for instance, you would test your REST interface directly instead of interacting with the DOM elements.
For smoke or regression tests UI are very useful. If there is a need to automate these, there are some dangers to consider. First, you should always write your test and don’t record them because recorded tests rely on automatically generated xpaths that brake for every little change you may do to the code. Best frameworks to write these tests are Selenium IDE, FireBug and Python using along with WebDriver to automate the browser interaction.
Code thinking.
UI tests have to have easy to find elements so you don’t have to rely on complex xpaths. Adding class or ID elements where you usually wouldn’t , will be frequent.
Don’t write tests for every small corner case because they are expensive to write and take too long to run. Better to focus on the cases that explore most of your functionality. If you write too many tests at this level you will probably test the same functionality that you already tested in the past in your unit tests.
And this is my final answer:
You need to consider Mike Cohn’s analogy – the test pyramid. It will help you decide what kind of testing best to be done in a certain situation.
At the bottom of the pyramid are the solid test units they are the foundation of the test strategy – they can provide you with a fast feedback.
At the top, occupying the smallest part of the pyramid , are the UI tests. They interact with your UI directly(for example Selenium), but are costly and very slow on feedback. They can become very brittle and hard to maintain.
At the middle of the pyramid there are integration tests that do not require an UI. In Rails, for instance, you would test your REST interface directly instead of interacting with the DOM elements.
For smoke or regression tests UI are very useful. If there is a need to automate these, there are some dangers to consider. First, you should always write your test and don’t record them because recorded tests rely on automatically generated xpaths that brake for every little change you may do to the code. Best frameworks to write these tests are Selenium IDE, FireBug and Python using along with WebDriver to automate the browser interaction.
Code thinking.
UI tests have to have easy to find elements so you don’t have to rely on complex xpaths. Adding class or ID elements where you usually wouldn’t , will be frequent.
Don’t write tests for every small corner case because they are expensive to write and take too long to run. Better to focus on the cases that explore most of your functionality. If you write too many tests at this level you will probably test the same functionality that you already tested in the past in your unit tests.
Comments
Post a Comment