Productivity

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

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.

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.

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.