Much like every site on the internet, we use cookies to help analyze traffic and improve our website. As outlined in our privacy policy, any information is only used internally and is not shared with outside organizations.
Learn More

We have just posted a new release of Test Design Studio, and it is available for download.

The most notable additions to this release are related to the build process.  For those who may not be familiar with this feature, the build process allows Test Design Studio to perform routine tasks associated with the collection of files in your project.

A Little Background on Build

Perhaps the most important of the build tasks is the ability to update your QuickTest tests.  QuickTest does not have a centralized approach to test configurations unless you use Business Process Testing.  Each test is a self-contained entity requiring its own configuration.  This is great if you write tests in isolation, but most users typically create a suite of many tests for a given application.  Shared resources such as function libraries and object repositories are used by most (if not all) of those tests.  When you add a new library or object repository to your shared resource pool, you must update each test to add this new resource.  That process is time-consuming and easy to overlook.

The Test Design Studio build process changes that!  Test Design Studio already has an excellent project-centric approach to test management, and keeping your tests updated is as easy as running the build process.  Once initiated, Test Design Studio looks at all the tests in your project as well as all the shared resources.  Each test is then opened in QuickTest through their API, object repositories are associated with each action, and function libraries are associated with each test.  Test Design Studio even makes sure you have the proper add-ins set.

When I develop automated tests, I place most of my functionality in reusable function libraries.  I keep libraries small and each one focuses on specific aspects of the application.  This keeps my code organized and easy to manage, but can easily create 10 to 20 function libraries.  Managing that many individual files would be cumbersome without Test Design Studio.  When I need a new test, my actions are simple:

  1. Add the test to my project using the ‘Add New Item’ command and selecting my QuickTest file template
  2. Right-click the file in Solution Explorer and select ‘Build’

 

That’s it!  My new test is immediately configured with all the function libraries and object repositories that are defined for my project.  When I need to add a new function library to my projects, the process is equally simple:

  1. Add the library to my project using the ‘Add New Item’ command and selecting library file template
  2. Right-click the project in Solution Explorer and select ‘Build’

 

Just like that, Test Design Studio will process all of my tests to make sure they reference the new library.

What Changed in New Release

The build process is key to increasing your productivity and working in conjunction with QuickTest.  One of our newer customers recently posted a series of suggestions for improving the build process, and we were pleased to make those enhancements (you know how you are, and thank you!).

Hint: If you have an idea on how to improve Test Design Studio, it’s a great idea to share it!

Test Left Open after Build

If you initiate the build process for a single test, Test Design Studio will now leave that test open in QuickTest after the build is complete.  This is a great time-saver when actively writing and debugging a test since you can essentially use the ‘Build’ command to open the test in QuickTest (something always available off the context menu) but also ensure that all resources are properly associated to the test.

Version Control Improved

We made many adjustments to how version controlled tests are managed.  A test must be checked out in order to modify it, so the build process will check out any test that was not already checked out.  If no changes were necessary from the build, that check-out will be cancelled.  When the test is modified, it will be checked back in only if the test was not already checked out.  Those tests that were already checked out before initiating the build will remain checked out afterwards.

Keeping a test checked out proved to be a complex task due to an issue with the QuickTest API.  If you save a version-controlled test and try to close it without checking it in, QuickTest displays a prompt asking if you want to check it in.  It even does this if you are using the API, and that dialog was blocking the build process while waiting for user input.  Even worse, the dialog displayed by QuickTest was often not visible on the desktop giving the illusion that Test Design Studio had stopped responding.  To keep the build process operating smoothly, we actually had to use GUI automation to detect and dismiss that dialog when displayed.

Build Selected Command Updated

The ‘Build Selected’ command was originally designed to build the selected item in the Solution Explorer tool window.  For those that do not have the Solution Explorer track the currently selected document, this caused some confusion.  If you had one test selected in Solution Explorer but were actively editing a different test in an editor, the ‘Build Selected’ command would build the test in Solution Explorer instead of your current document.  That has now changed.  The command will only process the selection from Solution Explorer if that tool window is selected when activating the command.  Otherwise, it will attempt to process the actively edited document.

Summary

For those not familiar with the build process, we hope you integrate it into your project management process.  For those already using it, we hope you enjoy these enhancements.  Thank you again to the customer who brought these suggestions to us, and keep that feedback coming!  We all benefit from the ideas of others.