Today’s Tip Tuesday article is about storing test data in the JSON file to improve and expand the diversity of tests in your automation.
You use Page Object Model to separate your tests from the pages to improvetest automation performance, but do you separate your test data from the tests? One way to improve and expand test automation is by keeping your test data (e.g. users, attachments, test content, etc.) in a JSON file that you can pull from. This allows you to create additional, diversified tests easily.
When I started out on my crazy adventures in test automation, I stayed close to the browser. The first automation framework I worked in was WATIR and it was awesome. It is a clean and straightforward framework which is what drew me to it. I was introduced to my first headless automation tool by one of our UI Engineers. The tool set was CasperJS and PhantomJS. While they were great tools, I really wasn’t sure how to use them correctly, especially since I wasn’t watching my tests execute anymore. So I played with them for a while and that was it.
I had hit a wall, my test automation was taking over 5 hours to run and I wasn’t sure what I could do to bring that time down. I knew that there were environmental issues that were slowing down my tests. Around two hours in the number of page timeouts jumps up to nearly 50%. WebDriver has never worked well with test environments that were extremely under powered, but there was more to it than that. This was a sudden jump in time of execution and timeouts.
Eventually we found the problem, but after all the research, I wanted to loose my head.
I was knocked out! I was asked a question about API testing and I was mentally knocked out. While I have tested APIs before, I have been focused on front-end testing lately. The last time I did it in an automated fashion was as a proof of concept. At that moment, I realized I have been focusing on front-end test automation too much and I really needed to brush up on my back-end testing skills.
When your test automation is running fine, everything is great with the universe!
Then it happens. A test cases fails and your trace isn’t entirely clear as to where it failed. Even when the trace is clear, you still have to walk through the test steps to capture a screenshot for the bug. Imagine being able to capture screenshots at the moment of failure.
Some test automation require you to look at the page source to confirm tags. This article covers opening the view source to assert tags are present using Ruby. Here’s a quick way to validate text on page source using ruby. Continue reading “Checking View Source While Testing”