• Testing & ALM

    30 Days of TDD – Day 13 – More Stub Features

    October 10, 2013 Share
    In the last post I introduced you to Stubs and wrote a simple example that returned a canned value for a method based on a parameter. In this short post I’ll show you another feature of stubs that can help ensure that your subbed method is be called correctly.

  • 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.

  • 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.

  • Testing & ALM

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

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

  • Testing & ALM

    30 Days of TDD – Day Nine – Refactoring Basics

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