Productivity: Testing

[Updated: Fixed a pasting error] Earlier today I posted up a video on Telerik TV: Five in Five. It’s five things I love about Test Studio in five minutes. (Well, the video is 5:54 long, so it’s not quite six minutes which means it’s still five minutes. Mostly.) My five favorite things about Test Studio are: The Element Repository. Centralized, managed handling of element locators? Sign me up. This is perhaps my most favorite part of Test Studio. Flexible find logic. Yes, you can write various Xpath selectors in WebDriver, Watir, or other tools, but Test Studio’s chained find ...

How much time to you spend documenting your test cases? Most of the time it’s “too much!” Test Studio’s Storyboard export feature can get you a great start on documentation with the click of a button. Test Studio captures storyboards as you record your test, giving you a visual walkthrough of what your test is doing in a series of frames, one per test step. Each frame shows the exact state of the UI after that step is completed: Navigation, coded steps, and other non-visual steps are represented with a plain frame and a generic description of the action: Storyboards ...

Getting started with mocking can be hard. In this article, I describe the path that I took on my way to becoming a frequent mocker.

[Update: Added links for Hexawise and Allpairs, which I’d meant to do earlier.] Data driving, also often called parameterization, is a wonderful way to increase your test coverage though parts of your system; however, it’s also a seductive, alluring tool that can needlessly explode your tests’ complexity and execution cost. Let’s tackle the cons of data driving first, then walk through how it can, when mindfully used, lend some great value to your automation suites. Problems with Data Driving Automated test scripts need to be treated like production code—because they are production code! With that in mind, as test ...

I thought I’d follow up that last post on Using Data Driven Testing Wisely with something specific around the size of the dataset for a data driven test (DDT). What’s a good size for a DDT? As with everything in software engineering/testing, the answer is “42.” That, or “It depends.” In all seriousness, the right size of a dataset for a carefully thought out scenario does indeed depend. My payroll algorithm in the last post was a simple test set. You may be working something much more complex relating to finance, rocket science, or environmental controls. Every situation’s different, but ...