Are you (as a developer) inundated with frequent status updates? Requests like: “How far are you?” “What did you do today?” “Where are we?” Or are you a project manager that requests frequent status updates? Then this post is for you.
I’ve written about why builds are absolutely essential in modern application development (Part 1) and what why Team Build is a great build engine (Part 2). However, if you don’t include unit tests in your builds, it’s like brushing your teeth without toothpaste – there’s a lot of movement, but it’s not the most effective way to do things. In this post, I want to put forward a few thoughts about why you absolutely need to be unit testing.
Note: This post is NOT about TFS and Project Server integration – this is for adding, editing and deleting work items using MS Project.
Update 2013-08-30: The extension is now available for VS 2013.
In my previous post I wrote about why you should be doing automated builds in general terms. In this post I’ll show you how TFS’s automated build engine gives you consistency and quality in your build processes. There are other build engines, but if you’re using TFS for source control (and/or test management and/or lab management and/or work item tracking) then Team Build makes the most sense as a build engine since it ties so many other parts of the ALM spectrum together.
A couple of weeks ago I was doing a road-show where I did demos of TFS 2012 and it’s capabilities. I do a 4 hour demo that shows an end-to-end scenario, showing capabilities such as requirements management and elicitation, work management, developer tools, quality tools, testing tools, automated builds, lab management and reporting all using TFS. I visited 9 different companies, and most of them asked, “Why should we do builds?” This is something I want to address – you need to be doing builds, and you need to understand why they are so key to successful and effective software development. Builds are no longer an optional extra!
Windows Store applications are slowly becoming more popular. If you’re going to do any Windows Store development, you’ll need to shift a few paradigms in how you code – and how you test. There are hundreds of webcasts and blogs detailing Windows Store programming, but I want to explore testing Windows Store apps.
Late last year I uploaded my first VS Gallery contribution – Colin’s ALM Corner Checkin Policies. One of the policies in this pack is a Code Review Checkin Policy. I blogged about it in this post.