Microsoft ALM - Configure agent settings

While creating a build agent in the TFS admin console, you can define the agent name and the tags using the Team Foundation Administration Console and edit the agent properties as shown below.

You can also do this from inside Visual Studio by right-clicking the Builds node in Team Explorer, choosing Manage Build Controllers, and double-clicking a particular agent.

The “Agent Settings” section under “Advanced” section in the Process tab of the build definition can be used to influence agent reservation during the build process.  Under that section, you can specify which agent should run a build for that definition.  The property is “Name Filter” and it has an asterisk by default, which means that any available agent should be used, you can change that to any of the agents on the drop-down list”.   This will ensure that only the selected agent will get picked for that build. You can also redirect specialized builds to specialized build agents by tweaking the build agent reservation properties of the default build process template.

When we schedule a build, we can define an agent name filter, a set of tags and a tag matching criteria. This controls the way the Team Foundation Build Controller selects and reserves a Team Foundation Build Agent to perform our build.

Microsoft ALM - Configure Diagnostic logging in builds

TFS logs all builds to file using diagnostic verbosity by default.

Team Foundation Build provides tools to help you debug and resolve problems such as:

• Failed or partially successful builds
• Exceptions, errors, or warnings
• Unexpected events or results

View logs are enabled after the Staging location is configured for your build defintion. If you do not configure your build to produce output (Staging location) then the Diagnostics – View Logs menu will be disabled

After build completion, you can see the logs from the Diagnostics menu.

You can configure the level of logging verbosity from the Process tab of the build defintion. Change the logging level to verbose to explore and diagnose build failures

Microsoft ALM - Configure gated check-in

The Gated Check-in  builds help teams prevent broken builds by not automatically committing pending changes to the repository, but the system will instead create a separate shelveset that will be picked up by the Gated Check-in Build. The build itself will finally decide if the pending changes need to be committed to the repository based on the applied quality gates. In large teams, the main branch is normally gated and DEV/ feature branches are gate to offer more protection for the branch.

A gated check-in means that a build is performed with one set of changes from one developer and if that passes those changes are checked-in. This means that breaking changes never get it into the code base and it limits the pain to the developer checking-in rather than sharing that pain with the entire team when somebody makes a mistake.

Setting up a gated check in

1. In Team Explorer, make sure you are connected to the team project and then open the Builds page.
2. Choose the New Build Definition link or select a build, open its shortcut menu
3. Choose Edit Build Definition.
4. On the Trigger tab: Choose Gated Check-in.

When a user check-ins some code, Visual studio prompts for validating the build.

On selecting the Build Changes option, the team explorer window shows the status of build validation.

On successful build, TFS prompts the user the status of the check-in

Clicking the “Reconcile …” button will force an undo in the local workspace and pull the changes that were committed by the Gated Check-in build

Law of Demeter - Refactoring to Hide Delegate

The Law of Demeter is a design guideline for developing software, particularly object-oriented programs. In its general form, the law is a specific case of loose coupling. The fundamental notion of the law is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents), in accordance with the principle of "information hiding".

For E.g. the code given below shows that the client calls the method on the dependent object of the client rather than on the object itself. This increases the coupling between classes.

var manager = john.GetDepartment().GetManager();

The Hide Delegate refactoring principle can be applied to this design to solve the issue.

public Manager GetManager()

{

    return Department.GetManager();

}

What, when, how - dummy, fake, stub and mocks

Test doubles are objects that replace the dependent-on-component (DOC) in a test context so that the system under test gets an API as the real DOC and can perform activities against the API thinking that it is a real one!!!

There are different variations in the type of test doubles depending on the intent and context of usage. Ref: Test double patterns at XUnitPatterns.com.

In this post I’ll demonstrate the usage of the four main test doubles (Dummy, Fake, Stub and Mock) in the context of Microsoft Fakes and scenarios on how they can be implemented in your projects to enhance code coverage. All the definitions for the patterns are copied from Gerard Meszaros XUnitPatterns catalog.

Dummy: A dummy is an object that is passed as a method argument or used as an attribute in a test context but never actually used. Usually they are just used to fill parameter lists.

var dummyCustomer = new StubCustomer();

var sut = new Invoice(dummyCustomer);

var book = new Product("XUnitPatterns");

sut.AddItemQuantity(book, 5);

var actual = sut.GetAllLineItems();

Assert.IsTrue(actual.Count() == 1);

Fake: A Fake object actually have working implementations, but usually take some shortcut which makes them not suitable for production. The fake object need not have any of the "-ilities" that the real DOC needs to have (such as scalability); it need only provide the equivalent services to the SUT so that the SUT isn't aware it isn't using the real DOC.

var dummyCustomer = new StubCustomer();

var sut = new Invoice(dummyCustomer);

var logger = new FakeLogger();

sut.Logger = logger;

var book = new Product("XUnitPatterns");

sut.AddItemQuantity(book, 0); //Throws exception if quantity is less than 0 and logs the error. Should use the FakeLogger to write the message to log.

Stub: Stubs can replace a real object with a test-specific object that feeds the desired indirect inputs into the system under test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.

var dummyCustomer = new StubCustomer();

var sut = new Invoice(dummyCustomer);

var validator = new StubIProductValidator()

{

    IsValidProduct = (p) => { return true; }

};

sut.Validator = validator;

var book = new Product("XUnitPatterns");

sut.AddItemQuantity(book, 2);

var actual = sut.GetAllLineItems();

Assert.IsTrue(actual.Count() == 1);

Mock: A mock replaces an object the system under test (SUT) depends on with a test-specific object that verifies it is being used correctly by the SUT. Mocks insist upon behavior verification. The other doubles can, and usually do, use state verification. Developers perform assertions on mock objects to ensure that the behavior expectations were met during test execution

var dummyCustomer = new StubCustomer();

var sut = new Invoice(dummyCustomer);

var observer = new StubObserver();

var validator = new StubIProductValidator()

{

    InstanceObserver = observer,

    IsValidProduct = (p) => { return true; }

};

sut.Validator = validator;

var book = new Product("XUnitPatterns");

sut.AddItemQuantity(book, 2);

           

Assert.IsTrue(observer.GetCalls().Any(call => call.StubbedMethod.Name == "IsValid"));