Working with Visual Studio: Write Code Where Needed - Part 1

Every test automation project will require some level of coding to be successful. Test Studio’s record and playback creates powerful, maintainable tests, but you’ll still need to write code at some point to cover common, critical aspects such as configuration, backing APIs, or test oracles.

Setup and Teardown/Configuration

Complex tests require clear, flexible configuration actions that keep the overall test suite maintainable over the long run. Pushing setup, teardown, and configuration to code versus the system’s interface dramatically speeds up test execution by leveraging the system’s own internal functionality through internal APIs, web service endpoints, or database stored procedures.

Here are some common scenarios where a team might drop to code to handle specific situations.

Setup for CRUD Tests

It’s critical to keep test cases, manual or automatic, focused and granular. If we’re working with tests focusing on Create, Retrieve, Update, or Delete (CRUD) actions, then automation at the UI level should be focused on that specific scenario, not getting the system ready to test.

Let’s use a test which focuses on checking whether or not we can successfully create a forum post as a new user. The test is around creating the forum post, but we have prerequisites for a new user and a forum to create the post in. We could use UI automation to log on as an administrator and create both the new user and the forum, but that could easily take 30-45 seconds to work through. Moreover, we have to acknowledge that much of UI automation is brittle by its very nature.

Instead of using the UI to create the user and forum for the post, we should prefer to use existing API functionality within the system to manage that effort for us. (We need to ensure those APIs are properly tested elsewhere in the system, of course!) Using these APIs ensures our tests run faster, and we’re also keeping the overall test suite much more maintainable.

Configuration Actions

Part of keeping your test suite lean and focused on high-value tests is ensuring you’re not testing components which don’t make sense to test. Using coded steps to disable and re-enable these components during automated testing runs is a great way to keep your tests smoother and targeted to functionality your teams are writing.

A perfect example of this is the infamous CAPTCHA anti-spambot guards. We at Telerik often get questions on how to test CAPTCHA, and our constant response is “Don’t.” CAPTCHA is a tool provided by a third party, and generally speaking you shouldn’t spend your time testing someone else’s software.

Another example of a third party tool that doesn’t make sense to automate is TinyMCE, a popular open source rich text editor. TinyMCE has its own test suite validating its basic functionality. Why would you want to write tests to check this within your own system?

In both these cases it makes perfect sense to create configuration switches in your system to turn off this functionality and bypass it for your test automation. In CAPCHA’s case you would work with your system developers to create configuration options to remove CAPTCHA from workflows in your system. You can use coded steps to alter these configuration options using your own methods, or leveraging the various APIs under the System.Configuration.ConfigurationManager class.

You'll Always Need to Code

 Every successful automation project I've been involved with over the years has required some level of code. As wonderful a tool as Test Studio is, you'll find your teams delivering much better automation if you carefully focus on applying code at the right spots. Hopefully this post has gotten you started in that direction!

Coming up, in part two, we'll cover backing APIs, extended tests, and test oracles. More blog posts on the topic of Developer Testing: Developers and Functional Testing & Working in a Familiar Environment.

About the author

Jim Holmes

Jim Holmes is the Director of Engineering for Test Studio. He has around 25 years IT experience. He's a blogger and the co-author of "Windows Developer Power Tools" and Chief Cat Herder of the CodeMash Conference. Find him as @aJimHolmes on Twitter.

CodeProject