The devil is in the details (Visual Studio Team System test policy)

Edit on GitHub

Have you ever been in a difficult situation where a software product is overall very good, but a small detail is going wrong? At least I've been, for the past week...

Team System allows check-in policies to be enforced prior to checking in your code. One of these policies is the unit testing policy, which allows you to enforce a specific test list to be run prior to checking in your code.

How it is...

Now here's the catch: what if you have a Team Project with 2 solutions in it? How can I enforce the check-in policy to run tests from solution A only when something in solution A is checked in, tests from solution B with solution B changes, ...

How it should be...

Creating a custom check-in policy

To be honest, there actually are quite enough examples on creating a custom check-in policy and how to install them. So I'll keep it short: here's the source code of my solution (VS2008 only).

kick it on DotNetKicks.com

This is an imported post. It was imported from my old blog using an automated tool and may contain formatting errors and/or broken images.

Leave a Comment

avatar

3 responses

  1. Avatar for Nick Berardi
    Nick Berardi June 13th, 2008

    Hi,

    I am an avid user of TFS since its initial release in 2005. I am curious. How did you get two different solutions under your Team Project? Or is that an artistic license that you took in order to illustrate a point?

  2. Avatar for maartenba
    maartenba June 13th, 2008

    The screenshot is fake, true :-) But it's quite easy to put more solutions in one Team Project? Whenever you want to attach a solution to source control, you can pick the same Team Project for each solution.

  3. Avatar for Nick Berardi
    Nick Berardi June 13th, 2008

    Oh yeah I know you can store unlimited files under one TFS project. I was just curious about the screenshot.