 |
| image credit: www.macforensicslab.com |
TLDR
There is important misunderstanding that Context driven school of testing is against test automation and programming in general. In following example I will give an example that will help to refute such opinion.
Here is one context driven principle in action:
“Automated testing is not automatic manual testing: it’s nonsensical to talk about automated tests as if they were automated human testing.”
I am writing browser automation framework for one of my client. Web application is one page application with “heavy” javascript involvement. Framework contains script that does following:
Given that I sign in
When I open xy application tab
Then there is xy amount shown
And I log out.
I wrote that script with following mission, to check how javascript behaves in repetitive action.
After I ran script, I was not able to login to application. UI interaction is blocked, which is not unusual when you have javascript driven UI. Browser refresh action was shortcut to make application operational again.
I tried to reproduce the issue without the script, but without success. Difference between human actions and script actions were in timings. Log out step was done in script much faster. And that was cause of issue.
While application tab was still loading, script did log out action (interrupt), which cause unhandled exception in javascript.
This example supports context driven principle, that automated testing extends human testing, it does not replace it.
