• Testing & ALM

    30 Days of TDD – Day 12 – Working with Stubs

    October 07, 2013 Share
    “Mocking” is one of those magical concepts derived from OOP that makes TDD possible. But as you saw in the last post, there are many different kind of mocks and each has its own strengths, weaknesses and purposes. We’ll discuss most of these types of mocks at some point in this series. But in this post I’m going to demonstrate one of the most common type of mocks you’ll use; the Stub.

  • .NET Testing & ALM

    It's All About the Data

    October 04, 2013 Share
    We collect a lot of data during the testing process, but whether we put it to good use is a different story.  We run individual tests of test cases, and determine if they pass or fail.  If they fail, we determine at what point they fail, and provide the steps necessary to replicate that failure. We look for performance of individual transactions early on in the testing process, then when our goal turns toward deployment, we add virtual users to determine the behavior characteristics of the application and servers under stress, as well as whether it can successfully handle the ...
  • .NET Testing & ALM

    [A Few Tips] How to Decompose User Stories and Assign Tasks

    October 03, 2013 Share
    Decomposition into Tasks Your backlog is normally comprised of requirements in the form of User Stories which depict the resulting value required by the users of the system. During iteration planning, teams take the highest value requirements and assign them to the current or next iteration, filling the iteration to capacity. Agile teams typically do not decompose requirements into work tasks until they are assigned to an iteration. Agile teams spend the first few hours of each iteration going through iteration planning, and a part of that process is the decomposition of requirements into work that can be completed by ...
  • Testing & ALM

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

    October 02, 2013 Share
    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.

  • .NET Testing & ALM

    New troubleshooting articles for Test Studio Load Testing

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