Hey!
So, after a long vacation its time to write a new post… And this post is really interesting!
Data-Driven testing!!! Yay!!!
So, What is it?
Let’s sum it up as one logic that can test different scenarios based on the data placed in it…
Your test framework should provide generic test logic to reduce maintenance and improve test coverage.
The input of the test should come from an outside source (XML, CSV, DataBase or whatever).
The framework should understand from your input file what is the expected result, what is being tested and how to test…
How to use it properly?
Well, its rather complicated and not really maintainable to create your entire framework to be data-driven…
BUT!
If you have a test or a segment in the system that can be tested with different scenarios thats the time! (avoiding code duplication and the ability to increase coverage easily! thats awesome!!!)
Where and on what for example?
Lets say we have a test that wants to test our form validation and proper errors received. this test logic will always do the same thing:
- Login
- Navigate to the form
- Try to input invalid input
- Validate error message received, validate form wasn’t saved, validate proper error message.
So, for this test logic let’s imagine our form has one field a number only mandatory field…
So, we can duplicate the logic, but tomorrow we might want to add another test, and its a lot easier doing so when its done from an outside file…
So what will our outside source contain?
We will have an outside source and each line in it will be a test running on our logic above… we can have a scenario that tries to put letters and validate that the error message is something like: “This field accepts only numeric input”… We can test the mandatory field and leave it blank and validate the error message now: “Mandatory field”…
So, with this solution we can add easily to our outside source more and more cases without changing the code, so if tomorrow the field will not be mandatory anymore? NO PROBLEM!!! just delete that line.
Of course it was a really simple example, but think on a large scale how flexible this is and how easily maintainable it is.
What to avoid?
- Your outside source should contain the input or the “what we are testing” and the expected result.
- Refrain from writing what is the logic we are testing on the outside source, just what gets in and what is expected.
- Refrain from creating too generic code – keep using proper clean code principals while writing your tests and test methods.
- If you can’t follow the principal above, avoid using data-driven on that test – maybe this test or method is not meant to be data-driven…
Keep automating,
Raz Shuty.
For more information about AutoMind and what we do – Click Here
Don’t forget to follow my blog to get new posts live into your inbox
AutoMindBlog 