Telerik blogs

Latest

For the latest product updates, please visit Release.

  • Productivity Testing

    30 Days of TDD – Day 11 – What’s the Deal with “Mocking?”

    A goal of well written unit tests is to keep your test isolated. This means that even if your code under test relies on or is dependent on another class or external service you should be able to write your tests to exclude these dependencies and test only what’s in your current class or method. Sound impossible? It’s not, in fact if you’ve read my previous posts on Dependency Injection you already know half the answer to this problem. The other half of the solution is mocking.
    October 02, 2013
  • Productivity Testing

    New troubleshooting articles for Test Studio Load Testing

    Now that we have a new Load Testing architecture, we're re-organizing the troubleshooting articles to bring everything up to speed. Most of the old issues with load have been resolved. For those that remain, we're creating new articles to help you resolve them more easily. First, if you don't get any load traffic when making requests to localhost, use the machine name or IP address. Simple. Next, some load tests still record duplicate dynamic targets. While there's no way to avoid this, you can make sure to select the repeated variable in all steps it is used ...
    September 30, 2013
  • Productivity Testing

    Extending Test Studio in the Real World

    Updated: Fixed a few formatting and badly positioned graphics. No tool can ever possibly meet every team’s needs out of the box. It’s crucial to select tools that are extendable or customizable to handle things specific to you and your team. Test Studio gives you the ability to customize a number of things under the hood. One great feature is tying into events for test lists in order to handle setup or teardown steps. This lets you do things like load baseline datasets, clear out test-generated data, or perform configuration actions. The post below is written by Ivaylo Angelov, a ...
    September 30, 2013
  • Productivity Testing

    30 Days of TDD – Day Ten – More Refactoring and NUnit Features

    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.
    September 30, 2013
  • Productivity Testing

    30 Days of TDD – Day Nine – Refactoring Basics

    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.
    September 27, 2013