Productivity: Testing

In the last post I showed you how from time to time it is necessary to change our code to enhance readability, make maintenance easier or to optimize the codes performance. This practice is called “Refactoring.” Normally making these kinds of changes can be a nerve-wracking experience for developers as they can’t be certain that their changes aren’t breaking something else. However, having a suite of unit tests the exercise your business code enables you to refactor your code without worry; as long as your tests pass you know that your code still satisfies your business needs. In addition to our code, sometimes our unit tests themselves need some refactoring. This post explains how to refactor your unit tests and demonstrates a few NUnit features that will help us with this endeavor.

As time goes on in any software development project you’ll no doubt find inefficiencies in your code that you would like to remove. Other times you’ll receive new requirements that are going to necessitate large scale changes in your existing code. And you will still occasionally find code that you’ve written in the past that will make you ask “What was I thinking when I did that?!” When these situations arrive, it’s time to look at refactoring your code.

I’ve previously discussed a bit of the TDD workflow; start with a requirement, derive a test from the requirement, write just enough code to make that test pass, repeat. This is sometimes referred to as “Red, Green, Refactor” which I’ll be coming back to several times over the course of this series. In this post I’ll show you how this approach can be extended to dealing with software defects.

Now that Test Studio has a new scheduling and load testing architecture, our documentation updates can help you get the most out of our new and old scheduling and load testing features.  First, we have a new guide for an existing feature: our new Export Load Results walkthrough shows how to convert your Test Studio Load Test results to HTML or Excel spreadsheet format. Next, we have some help for responding to some load testing problems that may have popped up for a while: the No Results Data article explains what to do when you aren't getting results back ...

Test Lists are a great way to organize tests and get execution results summarized. Telerik Test Studio includes the standard “Static” Test List that allows you to add existing tests from your project, but there is a small maintenance penalty for using the static list because each time you add a new test to your project it must be added to one of the existing test lists. One of the underlying principals of Test Studio is to decrease the overall maintenance cost traditionally associated with automated testing. Within the world of test lists we have done this by creating the ...