Latest

  • Testing & ALM

    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
  • Testing & ALM

    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
  • Testing & ALM

    Why is My Visual Studio Slow To Start?

    JustCode works very hard in the background to make you as productive as possible without getting in your way. In order to do this there is some startup work that must be done, and this can affect the start up time for Visual Studio. Read here to see what's going on behind the scenes.
    September 25, 2013
  • Testing & ALM

    30 Days of TDD – Day Eight – Dealing With Defects

    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.
    September 25, 2013
  • .NET Testing & ALM

    The Importance of Measuring Iteration Velocity and Capacity for Agile Planning

    When iteratively planning an Agile project where the team partitions work into timeboxed iterations, understanding capacity is very important. Planning an iteration is very much like using a bucket to scoop water out of a pool, where the pool represents the complete set of backlog items on your project and the bucket represents the amount of work that can be accomplished in a single iteration. Understanding how much water a bucket holds will give you an idea of how many buckets are required to empty the pool. Similarly, understanding how much work your team can deliver in an iteration will ...
    September 25, 2013