Windows Azure has some pretty cool diagnostic features built into the SDK, which allows you to write to a log store held within table storage. Typically to activate logging it is as simple as adding the following startup code within a cloud service, whether it be a web or worker role, which will initialise your service to write to the Azure logs table.

private DiagnosticMonitorConfiguration DiagnosticMonitorConfiguration()
{
    var diagnosticMonitorConfiguration = DiagnosticMonitor.GetDefaultInitialConfiguration(); 
    diagnosticMonitorConfiguration.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
    diagnosticMonitorConfiguration.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);
    return diagnosticMonitorConfiguration;
}

DiagnosticMonitor.Start("Microsoft.WindowsAzure .Plugins.Diagnostics.ConnectionString", diagnosticMonitorConfiguration);

You can then use the trace classes to write to the log. The below shows writing to the log with the log level set to exception.

Trace.TraceError("An exception has occured for UserId {0}, exception is {1}, userId, ex.ToString());

The diagnostic support allows you to configure things such as the log level and the frequency to batch write your logging to table storage. It can also be used to configure performance counters, which includes being able to specify what performance counters to monitor on a service, as well as a few other things.

Within Azure commonly you would have a storage account which is used only for logging, monitoring etc. For logging Azure creates an entity in table storage which is called the WadLogsTable. This entity will include any logging message, the logging level, which role the logging was from etc.

A requirement I recently had was to be able to query this table and return anything logged with a logging level of Exception or above. The idea was to take this data from table storage and move it into a SQL database, where the data can be collated and be able to run a number of Reporting services reports over the data, to provide stats on the frequency of types of errors over the course of a day etc.

Within the Azure SDK, there is no built in TableServiceEntity which represents the WadLogsTable, therefore you have to role your own. The class below is an example of this. I have created a class which inherits from TableServiceEntity and includes all the properties with the same name and data type as per the WadLogsTable within table storage. The TableServiceEntity is the base class for any entity that is stored within table storage.

namespace AzureDiagnosticsService.Domain
{
    public class WadLogsTable : TableServiceEntity
    {
        public string Role { get; set; }
        public string RoleInstance { get; set; }
        public int Level { get; set; }
        public string Message { get; set; }
        public int Pid { get; set; }
        public int Tid { get; set; }
        public int EventId { get; set; }
        public DateTime EventDateTime
        {
            get
            {
                return new DateTime(long.Parse(PartitionKey.Substring(1)));
            }
        }
    }
}

To query table storage, I need a class which inherits from TableServiceContext, as per the Repository class shown below. You can think of the TableServiceContext as the equivalent of the DbContext, which is used within the Entity framework.

Unlike the Entity framework where you can use the same DbContext against multiple entities defined within the context, an instance of the TableServiceContext can only be used against a single table storage entity type. This may seem a little odd at first but it actually makes perfect sense for the reason that table storage is a completely different beast to a standard relational database such as SQL server. In table storage there are no relationships, each table is independent from any other.

The code below shows a generic repository, where T is a TableServiceEntity. The repository would be used to perform CRUD operations against entities stored within Table storage in Azure. For the sake of simplicity this example only shows a generic LoadBy method, operations such as Add, Update and Delete are omitted.

The results returned from the query are automatically mapped to the WadLogsTable TableServiceEntity, as the property name and data types match. No need for Automapper here.

public class Repository<T> : TableServiceContext, IRepository<T> where T : TableServiceEntity
{
    private readonly string entitySetName;

    public Repository(string baseAddress, StorageCredentials credentials) : base(baseAddress, credentials)
    {
        entitySetName = typeof (T).Name;
    }

    public List<T> LoadBy(Func<T, bool> expression)
    {
        var result = CreateQuery<T>(entitySetName);
        return result.Where(expression).ToList();
    }
}

The LoadBy method within the repository above takes a Func with the following signature Func<T, bool>, where T is the WadLogsTable in this example. The idea of inserting a Func expression into the the LoadBy method allows this method within the repository to be completely generic, by being able to pass in any expression to be performed against this entity or any other for that matter. Let me show you an example of the expression below.

public class WadLogsQueryObject : IWadLogsQueryObject
{
    public Func<WadLogsTable, bool> ByLastMinutes(int minutes)
    {
        Func<WadLogsTable, bool> expression = x => x.PartitionKey.CompareTo("0" + DateTime.UtcNow.AddMinutes(minutes).Ticks) >= 0;
        return expression;
    }
}

The above expression which I am going to refer to as the query object, is the lambda that I am going to use as my filter. The query object allows me to pass in a parameter in this case the last number of minutes I want to retrieve WadLogsTable entries for. Within these QueryObject classes I can store together all the operations I would want to run against a particular entity. Storing these queries in a separate class and passing them into the repository also helps make the whole thing testable when using Mocks.

In most cases you would probably want to query the WadLogsTable by the timestamp to retrieve for example all the logs for the last hour lets say. An entity within table storage always has two keys, the PartitionKey and the RowKey. These are the only two columns which are indexed and therefore optimised for running queries against. With the WadLogsTable the convenient thing is the PartitionKey is actually the timestamp, with an additional zero appended to the beginning. This means that I can run a query against the table using the ParitionKey substituting the leading zero as is shown above in the Func expression.

Having loaded this data into my object, I could then do what I liked with it, using Linq to objects if I wanted to filter the results any further and persist it to anywhere of my choosing if necessary. The same trick can be used for not only the WadLogsTable but it can also be used for the WadPerformanceCountersTable and WadWindowsEventLogTable.

I hope this post shows you how to access logging data from Azure and also has shown you a few nice tips and tricks towards the start of a nice reusable repository for table storage.

The post Querying data from the WadLogsTable in Windows Azure appeared first on DEV SCRUM .NET.

I recently set up a load test rig in Azure to run load tests against cloud services also hosted within Azure. This post does not talk through how to create the rig, there is a great set of articles on the Windows Azure developer site which does exactly that. You can read them here Setting up a Load Test Rig in Windows Azure

The intention of this post is to discuss the components that make up a test rig in Azure and talk through some of the lessons I learned from setting up the rig, hopefully so you don’t have to feel all the pain I had setting it up for the first time.

The below diagram shows the architecture of the Load Test Rig.

Windows Azure Load Test Rig Architecture

Local Machine
This is simply the machine that kicks off the test, such as the developers or testers machine. A load test can be started from within Visual Studio Ultimate. However before you start a test to run against a controller hosted remotely inside Azure, you need to configure the test controller settings.

The first think todo is to add a testsettings file to the solution that contains the load tests. The testsettings file allows you to specify settings that are applied when you execute your tests in Visual Studio. To run a test against Azure you need to set the test execution method as “Remote” and include the name of the controller. This is shown below

Visual Studio Test Settings File Configuration

Full details of configuring testsettings can be read here. http://msdn.microsoft.com/en-us/library/ee256991.aspx

You also need to set the controller and the database the test results will be stored in on the “Manage Test Controllers” option found under the “Test” menu in Visual Studio.

Windows Azure Manage Test Controller

Visual Studio Test Controller
The controller is responsible for starting a test run. When a load test is executed from the local machine the assemblies required to run the test are copied to the controller. The files are copied to a directory on the controller in the following location D:\Users\[USER]\AppData\Local\VSEQT\QTController. Each deployment will have a further directory named with a unique GUID where the files are copied.

Once the files have been deployed the controller is responsible for sending the load test and deployed assemblies to all the agents that are configured to run the test. The controller polls the agents to see when they are ready. When all agents are initialised the controller then sends a message to all the agents to start the test.

The controller machine is also responsible for collating all the results from the test run. The results are stored within a SQL Server database. The database is called loadTest2010 and is created when the test controller is installed on the instance. To be able to connect to the SQL database from the local machine you have to add a firewall rule to allow TCP traffic on port 1433.

You can think of the controller as a service broker.

Visual Studio Test Agent(s)
The agents are effectively the clients that execute the tests. The more agents you have the more load you can thrust upon your system, this is where Azure comes in great for the ease of spinning up additional agent instances. All the agents are running a service that listens from requests from the controller.

There is no limit to the number of agents that can be created. Each agent will run the same load test in a test run. Agents can be given a weighting, which can be seen as the proportion of the overall load that each agent runs.

System under Test
The system under test is your system, made up of web and worker roles that you want to test. Performance counters can be collected from any Azure instance as long as they are part of the same Windows Azure Connect group as the local machine, test controller and test agents.

Windows Azure Connect Group Setup
In order to create a load test rig in Azure and run the performance tests against services hosted in Azure, all components must be part of the same Windows Azure Connect Group. To add all the machines into a virtual network every machine must have the same user account, must have the Windows Azure Connect endpoint installed with the same activation token and must be must be added to the same virtual network group from within the Windows Azure Portal.

• Configure User Account
  The same user account with administrative privileges must be created on all nodes that form part of the virtual network. This comprises of the local machine, test controller, test agents and every instance for which you want to retrieve performance counters for within the system under test.

  The easiest way to add an user account to all role instances in Azure is to use the remote access account, which can be configured in the service configuration file.

  <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
  <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="[USERNAME]" />
  <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="[PASSWORD]" />
  

  These service configuration settings are populated when you choose to “Configure remote desktop” settings, which can be accessed on the right click menu of the Cloud project within Visual Studio.

  You will need to create an account on the local machine which has the same username and password as to the account created on each role instance in Azure. It is this account that you need to be logged into when you start a load test run.

• Install Windows Azure Connect
  The Windows Azure Connect endpoint needs to be installed on the local machine and all role instances including the test controller, all the test agents as well as all role instances for the system under test. This needs to be installed with the same activation token.

  The activation token can be accessed by going to the Virtual Network tab within the Windows Azure Portal and clicking on the “Get Activation Token” option within the ribbon.

  

  The easiest way I have found to install the endpoint on each role instance with the given activation token is to run a custom bat file to install Windows Azure Connect and run the script as a startup task which can be configured within the service definition file of the cloud project. The following post covers how this can be achieved. Installing Windows Azure Connect as a Start-up Task

• Enabling Firewall Rules
  In order to retrieve performance counters from any instance within the system under test, you need to allow a couple inbound firewall rules on each Azure instance. These firewall rules are the “File and Printer Sharing” and “Performance Logs and Alerts”. These can be added manually on each instance from wf.msc and can be found under the predefined option, or you can use netsh advfirewall from the command line to automate the task. The following post covers how this can be achieved. Installing Windows Azure Connect as a Start-up Task
  
  
• Configuring the Windows Azure Connect Group in the Windows Azure Portal
  This requires creating a group under the Virtual Network option in the Windows Azure Portal and adding the machine instances to this group to allow all machines to function as if they are on the same network.
  

  Windows Azure Connect Group

As Windows Azure Connect is installed computers will appear at the bottom of the list. Simply edit the group and add each computer. As long as you don’t delete your services from either staging or production before you deploy, the machine names will always be the same, so once all machines have been added to the group from both staging and production you should not need to make any more changes to the Windows Azure Connnect group.

Using Windows Azure to host a load test rig is definitely a good idea. Once the initial setup is complete you have a reliable test rig which can be easily scaled up and down as required, so you don’t need to make any big investment in hardware to purchase machines to run the test controller and multiple test agents.

I hope this post provides some use to those seeking to setup a test rig within Windows Azure. I would love to hear any experiences others had had also setting up a rig within Azure.

The post Running a Load Test Rig in Windows Azure appeared first on DEV SCRUM .NET.

From within the Windows Azure Portal under the Virtual Network setting you can download and install a Windows Azure Connect endpoint, which is required on every machine that will form part of your virtual network. In addition to this they must all be installed with the same activation token, which can be accessed for a particular subscription under the Virtual network tab and then by clicking on the Get Activation Token button.

The challenge was to be able to automate the installation of the Windows Azure Connect endpoint to all the instances every time I do a deployment, but only to certain subscriptions and also to ensure that when the Windows Azure Connect endpoint is installed that it uses the right activation token for that subscription. To accomplish this I used a parameterised start-up task.

Within the ServiceDefinition.csdef file within the Cloud project in Visual Studio, you can add custom tasks that are run on startup when a role is installed on Azure. This can be applied to a web or worker role using the Task configuration element located under the Startup element. This is shown below.

<WorkerRole name="MyService" vmsize="Small">
    <ConfigurationSettings>
        <Setting name="IsPerformanceTestRig"/>
        <Setting name="WindowsAzureConnectActivationToken"/>
    </ConfigurationSettings>
    <Startup>
        <Task commandLine="deployment\startup\InstallWindowsAzureConnect.cmd >> deployment\startup\installWindowsAzureConnect.log" executionContext="elevated" taskType="simple">
            <Environment>
                <Variable name="IS_PERFORMANCE_TEST_RIG">
                    <RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/ConfigurationSettings/ConfigurationSetting[@name='IsPerformanceTestRig']/@value" />
                </Variable>
                <Variable name="WINDOWS_AZURE_CONNECT_ACTIVATION_TOKEN">
                    <RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/ConfigurationSettings/ConfigurationSetting[@name='WindowsAzureConnectActivationToken']/@value" />
                </Variable>
            </Environment>
        </Task>
    </Startup>
  </WorkerRole>

The task runs a bat file called InstallWindowsAzureConnect.cmd. The >> deployment\Startup\installWindowsAzureConnect.log creates a log file which outputs the execution of the bat file.

You can parameterise a task by adding Variables which is shown above. There are a number of ways to obtain a value to set as the variable.

<Variable name="WINDOWS_AZURE_CONNECT_ACTIVATION_TOKEN">
    <RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/ConfigurationSettings/ConfigurationSetting[@name='WindowsAzureConnectActivationToken']/@value" />
</Variable>

The example above gets the value of a configuration setting which will be set in the ServiceConfiguration.cscfg file with its name set to WindowsAzureConnectActivationToken, and will set the WINDOWS_AZURE_CONNECT_ACTIVATION_TOKEN variable which can then be used in the bat file.

The following article lists the different options you have for setting a variable value. http://msdn.microsoft.com/en-us/library/windowsazure/hh404006.aspx

The following is the InstallWindowsAzureConnect.cmd file contents

@ECHO OFF

echo Installing Windows Azure Connect & Enabling Firewall

IF "%IS_PERFORMANCE_TEST_RIG%" == "false" goto END
deployment\startup\Wacendpointpackage.exe /i /s /m en-us /token %WINDOWS_AZURE_CONNECT_ACTIVATION_TOKEN%

IF %ERRORLEVEL% neq 0 goto ERROR_INSTALL
echo Windows Azure Connect Install succeeded

Echo Add Firewall Rules
netsh advfirewall firewall add rule name="File and Printer Sharing (Echo Request - ICMPv4-In)" dir=in service="File and Printer Sharing" action=allow protocol=ICMPv4 enable=yes
netsh advfirewall firewall add rule name="File and Printer Sharing (Echo Request - ICMPv6-In)" dir=in action=allow protocol=ICMPv6 enable=yes
netsh advfirewall firewall add rule name="Performance Logs and Alerts (DCOM-In)" dir=in action=allow program="%systemroot%\system32\svchost.exe" protocol=TCP localport=135 enable=yes
netsh advfirewall firewall add rule name="Performance Logs and Alerts (TCP-In)" dir=in action=allow program="%systemroot%\system32\plasrv.exe" enable=yes	

IF %ERRORLEVEL% neq 0 goto ERROR_INSTALL
echo Firewall Rules Added
goto END

:ERROR_INSTALL
echo Error Installing Windows Azure Connect.  Return code is %ERRORLEVEL% 
goto END

:END
exit /b 0

This file runs a executable called “Wacendpointpackage.exe” (which needs to be also deployed with the .cmd file). This is an exe created by Microsoft to allow you to install Windows Azure Connect from the command line.

Wacendpointpackage.exe /i /s /m en-us /token %WINDOWS_AZURE_CONNECT_ACTIVATION_TOKEN%

The /i switch is to install, /s is to run silently, /m sets the language and /token sets the activation token. This here utilises the %WINDOWS_AZURE_CONNECT_ACTIVATION_TOKEN% variable.

The script also allows some firewall rules on each role instance which are required to be able to access the performance counters on each Azure instance.

The only step left once deployment is complete is to go into the Windows Azure Portal and under the Virtual Network tab create a new group and add all instances to that group. It is important to remember that every role instance within Azure and any on premise machines must all have the same local user that is part of the administrator group.

The post Installing Windows Azure Connect with a start-up Task appeared first on DEV SCRUM .NET.

Pickles is an open source living documentation generator that works on feature files written in the Gherkin language and supports frameworks such as SpecFlow and Cucumber. Pickles is simple enough to use, you tell it where to find the features files, and then you tell it where to put the results. You can output the results in a number of formats including JSON, Word and the default option HTML.

You can get Pickles via NuGet with the following command

Install-Package Pickles

Pickles has a number of options to how you can invoke the generation of the documentation. This can be as a Nant task, an MSI task or even a PowerShell command. With these options it is very simple to add the generation of the documentation as part of your continuous integration process. Lets take the PowerShell example

Import-Module 'C:\Pickle\Pickles.PowerShell.dll'

Pickle-Features -FeatureDirectory 'C:\MyFeatures' -OutputDirectory 'C:\MyOutput'

A simple two liner. The Pickles NuGet package includes a PowerShell module, which you will first need to import. This module contains a single CmdLet called Pickle-Features. -FeatureDirectory tells pickles where to find your feature files. Pickles will search for feature files in this directory and also any sub directories. -OutputDirectory tells Pickles where to write the results too.

So a typical scenario like the one below found in SpecFlow.

Can be viewed as HTML through a web browser by running Pickle over the feature file.

We use TeamCity for our continuous integration. We have added a step to the build process to run Pickles from PowerShell to generate the documentation files. Then we have added an extra tab on the build results screen. so that it can always be viewed for every checkin. In addition to this we copy the files over to a virtual directory folder so they can always be accessed, directly in a browser without the need to also have to go to TeamCity. This now means that anyone in the office can view the feature files at any time with the same URL they can be sure they are always viewing the latest version.

The post Sharing your living documentation with everyone with Pickles appeared first on DEV SCRUM .NET.

1. Simplicity
If there is any doubt, there is no doubt! Keep it simple, don’t over engineer your code, don’t write your code so it can support that piece of functionality that you “might” want in six months but probably never will, don’t write your own frameworks when there are commercial or open source libraries out there that specially built to solve a particular problem. Code bases I have worked on that follow the “Keep it simple” principle are not only far quicker to write but are also ten times easier to maintain. The rule I like to follow is that the code should do precisely want it is meant too and nothing more, don’t plan for tomorrow as it may never happen or if it does the requirements you know today will likely change as well. If you follow good design principle such as SOLID, refactoring down the road will be much easier.

2. Consistency
The rule I like to follow is that if I look at any piece of code in an application, I will not be able to tell which developer wrote it. This would be because all code is styled and laid out the same, following the same conventions through out the application. It’s not hard to come up with a consistent approach to follow. Sit with your team and come up with it together, its fine to introduce new ideas during the project, but run it past your team first and get agreement on it. Introduce some patterns to follow across the system for everyone to follow. A few examples might be if I have a variable to represent an object called Customer call it customer, this way when I look at the code I know straight away what the variable is.

3. No Attachment
Developers can get quite attached to a piece of code they have written on a project. The rule is that any code is subject to change at anytime. This is particularly relevant on agile projects. As hard as you might try, you will not write all your code perfectly first time. Code changes, code should change, it is healthy for a code base to be refactored to continuously improve the code, hopefully with the backing of a good set of tests to give you the confidence to do so. The willingness to learn and adapt to new ideas and new ways of working should be an important trait of any developer.

4. Share
Not everyone can be an expert on everything but everyone should at least know something about everything. It is commonly the case that silo’s are born within a development team, in fact suddenly you can find yourself in a situation where you are completely stuck if that person takes a holiday or gets hit by a bus. A good consistent style, well structured self descriptive code and a good descriptive set of tests can ease this pain. Development practices such as pairing or even code reviews can also help. But also get the dev’s together and review each others code as a group.

5. Have Fun!
What I love most about being a developer is that there is always something new to learn. But I also love the collaborative aspect delivering solutions as a team. Keeping it simple does not mean development becomes boring! It can give you the opportunity to explore new patterns as a team to deliver a consistent approach

There is a trade off, that although today you will only write the minimum amount of code that you need, there will be times that tomorrow you might have to apply large refactors to your code to support new features. But this is not a bad thing. When you come to make the change you will have a much better understanding of the new feature you will need to support and you will also have learnt lessons from how you wrote the code to support the original requirement. The end result will be that you have a far cleaner code base that always does only what it is meant too.

My best advice to you is to plan for tomorrow on paper but deliver what you need today in your code base. Keep it simple, keep it consistent and involve the whole dev team.

If anyone can thing of a sixth law to follow, please share

The post The Five Laws of Software Development appeared first on DEV SCRUM .NET.

This blog post aims to introduce three guidelines to help improve the maintainability and readability of your unit tests, by

1. altering the layout of your test classes
2. reducing common noise
3. and improving readability

I have introduced these three guidelines recently into my team and have found that the quality and understanding of each test has greatly improved, in particular when refactoring or fixing bugs in existing classes.


1) Structuring Unit Tests
When unit testing properly, most public methods within an application will have multiple unit tests associated to it. These tests should cover the different outputs to a method based usually on a different set of input data. Given a class under test with a lot of public methods, the test class can quite often become quite overloaded and quite difficult without close inspection to see what each test method is actually testing, i.e. the method it is testing and the scenarios for which it is under test.

With this in mind I recently read a post by Phil Haack detailing a solution he had come across to improve the readability of what each test class is actually doing. The solution is simple. For each public method you are testing, in your unit test class, create a nested class to encapsulate all the test methods for a given method. This is effectively grouping together tests by public method. This may seem like overkill at first, but to avoid repetition, you can define the setup and teardown methods in the base class. This means all the nested classes can inherit the base to reuse anything that should be shared.

The following example below shows the basic structure of a test class, which tests two public methods, the first called Get, the second Post.

    [TestClass]
    public class BlogPostTaskTests
    {
        protected Mock<IBlogPostRepository> blogPostRepository;

        [TestInitialize]
        public void Setup()
        {
            //shared setup, generally just initialising mocks
        }

        [TestClass]
        public class TheGetMethod : BlogPostTaskTests
        {
            [TestMethod]
            public void HappyPath()
            {
                //arrange
                //act
                //assert
            }

            [TestMethod]
            public void UnhappyPath()
            {
                //arrange
                //act
                //assert
            }
        }

        [TestClass]
        public class ThePostMethod : BlogPostTaskTests
        {
            [TestMethod]
            public void HappyPath()
            {
                //arrange
                //act
                //assert
            }

            //Additional Tests for the Post method here
        }

        [TestCleanup]
        public void Cleanup()
        {
        }
    }

2) Use the Test Data Builder Pattern for test data
Most unit tests require some input data for a method to test, and some output data to assert. I have found it too commonly the case that developers will duplicate instances of objects across multiple test classes, and initialise the object with hard coded test values. All this set up code within a test class adds a lot of noise to test classes which can make it difficult to understand what the test is doing.

Given the following class:

public class BlogPost
{
    public int Id { get; set; }

    public string Title { get; set; }

    public string Content { get; set; }
}

All to commonly you will find scattered across many test classes an instance of this class being initialised with test values to be used in a test.

var blogPost = new BlogPost
{
    Id = 1,
    Title = "My Title",
    Content = "My Content"
};

Following the DRY (Don’t Repeat Yourself) principle, I would recommend having a look at the test data builder pattern. The code below is an example of this for the BlogPost class. The class follows a number of conventions for consistency

• Create a class for each domain object. The name of the class follows [DomainName]Builder
• A private member variable for each property on the underlining class is added. This variable is assigned a default value.
• To allow you to override a default value, provide a method with the name With[PropertyName]. This method follows a fluent style to allow you to chain methods together. Only add the With methods when you need them. 95% of the time the default value will probably suffice, there is no value in adding code that is not ever executed.
• Add a Build method. This method will create and return a new instance of the object with either the default or overrided values.

public class BlogPostBuilder
{
    private int id = new Random().Next(1000);
    private string title = "My Title";
    private string content = "My Content";

    public BlogPostBuilder WithTitle(string title)
    {
        this.title = title;
        return this;
    }

    public BlogPost Build()
    {
        return new BlogPost
        {
            Id = id,
            Title = title,
            Content = content
        };
    }
}

An example of using the builder class

 var blogPost = new BlogPostBuilder()
                                    .WithTitle("Another Title")
                                    .Build();

Each unit test method should be responsible for initializing its own test data opposed to initializing the test data within the test setup. This makes it clear what data each unit test it utilising.


3) Use unit testing extension plugins to improve readability
I have recently been looking a very useful library called Fluent Assertions which provide extensions on top of unit testing frameworks such, with the aim of improving readability by following a more natural language, and reducing the amount of code that is required.

Fluent Assertions is effectively a set of extension methods on top of commonly used unit testing frameworks such as NUnit and MSTest.

As a simple example you could take the following Assert statement:

Assert.IsTrue(actualOutcome > 5);

and rewrite it as the follows:

actualOutcome .Should().BeGreaterOrEqualTo(5);

This is a simple example, but Fluent Assertions provides a wealth of extensions.

You can download Fluent Assertions via NuGet with the following command from the package manager console within Visual Studio.

INSTALL-PACKAGE FluentAssertions

and you can read about it here


I would recommend next time you write some tests, try following the three guideline above, I guarentee it will improve the maintainability and readability of your tests.

I would be very interested to hear any guidelines you follow to improve your unit tests. Thanks for reading.

The post Writing maintainable unit tests appeared first on DEV SCRUM .NET.

This hit list hopefully should provide some guidance for introducing or just improving BDD in your organisation. The list is spawned from my own experience introducing BDD as a new concept to my team over the last few months. It is in no particular order.

1. Don’t rush into automation.
   Undoubtably one of key outputs of BDD is an automated set of tests covering the scenarios raised against a story. However it is very easy to jump straight into the deep end. It’s not all about the tool and automated tests can be a maintenance nightmare. Get a proper framework in place, use the right patterns, such as the page object pattern, particularly if you’re writing your tests from the UI layer. Trust me this will save you a lot of rework.
2. Don’t spend hours arguing about the correct language to use. Try and land a few ground rules early, decide on terms to refer to elements of your system by and stick to it. Consult your domain experts. It is important to follow a ubiquitous language, so everyone is on the same page. Make sure everyone understands that the given, sets the context, when is an event and the then is an observable result.
3. See what others are doing. You didn’t invent BDD, Dan North did! Do some reading, there are many different people with many different views on the internet, read other peoples opinion and cut out and stick it in your scrap book, what you see as the points that will work for you and your team.
4. Write scenarios as a team. Don’t get one person to write them it’s not about one persons view, include the BA’s, testers and dev’s. Scenario writing is a team sport.
5. Have the conversation. the best thing about writing or even discussing scenarios is that it gets you thinking off the happy path track. Get the whole scrum team in a room and just talk through the requirements. As you start discussing a story in more detail, you’ll continuously hear the question raised, ah but what if I do this… or what if I do that. Ensure that this is also not just on the first day of the sprint. Put meetings in the calendar for regular review meetings.
6. Don’t add implementation details in scenarios. Avoid tying scenarios to the UI by referencing page elements or controls. Avoid tying scenarios to the architecture or technologies used under the cover. Everything that occurs under the UI cover is up to the architect and developers to design.
7. Add tests to continuous integration process as early as possible. When you do automate, get the tests running as part of the build as soon as possible, this keeps the test alive. The key to automated tests is maintenance. Making them part of the build process means you will know when they fail fast.
8. Use your scenarios. You’ve put the time in to write the scenarios, use them! Make sure they are held centrally under source control. Use them to develop against and particularly use them as test cases. Testers should be adding additional scenarios during the course of a sprint.
9. Include the SME (Subject Matter Expert), domain expert and customer Even if just to replay the scenarios against. These guys understand the problem domain more than anyone. In particular the customer is the one who will use the software.
10. Keep scenarios precise It has often been the case I have seen very long winded scenarios that have tried to capture multiple scenarios in one. No one wants to read an 20-30 line scenario. Keep them small and precise. Each scenario should cover a single case. Include examples for clarity.
11. Use examples to reinforce the scenario Examples bring scenarios to life! They make them dynamic and they provide test data to verify that the scenario meets it’s goal. Adding scenarios means that not only have you written your test cases upfront, you’ve also included the data by which to test it with.
12. Every scenario is negotiable and is subject to change at anytime. With the information available on one day a scenario might seem to be capturing the requirement. However additional information or even the realisation that the scenario do not cover all cases may lead to you and your team to revisit the scenarios and add, edit or even delete scenarios. If you do not change a suite of scenarios for a given story after they are first conceived, you are almost certainly doing something wrong. These changes may well also mean that acceptance criteria or even stories are subject to change too.
13. Your scenarios are your living documentation Make this available to the whole business, it’s also a great resource for your support team. If you do use tools like spec flow, the tools more often than not provides the ability to generate reports. Get these executed as part of your build and make accessible for everyone.
14. Make things visual. Using techniques such as story maps and including wireframes are a great way to visualise the requirements, and can be a great driver for conversation. Stick them on a wall so everyone can see them.
15. Sign off scenarios. A story can only be considered complete when all your scenarios have been implemented. At the end of sprint review meeting, when demoing whats been implemented in the sprint, replay the functionality to the team through the scenarios

For me agile is about making the invisible visible. What I mean by this is that agile is all about working as a team to deliver software. The key point to this is that the software is built collaboratively as a unit, with input from the business, customers, dev’s, BA’s testers. It’s about having the conversation, constantly reviewing, quick feedback and sharing the knowledge. It’s always worth remembering the agile manifesto, which gets this bang on in four simple steps!

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

I would love to hear any comments from your own experiences implementing BDD within your organisation. Thanks for reading.

The post Learning from mistakes with BDD appeared first on DEV SCRUM .NET.

The steps involved in dev box testing can be summed up with the following:

• The developer should demonstrate what he/she has done and run through the changes to the application that has been made.
• The developer should let the BA or tester run the application and perform at minimum happy path testing.
• This provides an opportunity for the BA to ensure that what has been produced meets the requirement.
• This allows the testers to understand what has been developed. The developer should share with the tester information about how to test the code change by means other than just the UI, i.e. any database changes, service calls etc.
• If any issues are found, the developer will fix them, and get them retested before anything is checked in.

Dev box testing commonly should not take any more than 10 minutes. It’s real value is that it allows for code to fail fast, which although that may seem a bit dramatic, is actually a really good thing! For example, even if you have a fantastically slick continuous integration process in place, the code still needs to be committed to source control, unit tests run and then deployed to a test environment before a tester and the BA can access the code change. This means there is always a delay in the code change being available to test, once it has been checked in. If a defect is found, such as a bug, a piece of functionality is implemented incorrectly or not at all, a vicious cycle begins. This is outlined in the diagram below.



Dev box testing helps by minimising the feedback cycle in terms of time. This is because code is tested before it is checked in. Any defects or requirements not implemented can be picked up and dealt with immediately. This also greatly improves the sharing of knowledge held by the developer with the testers. This knowledge sharing allows the tester to truly understand how the changes were implemented and understand how the application can be tested under the covers, away from just UI testing. Sharing this knowledge whilst it’s still hot, fresh in the developers mind is essential.

The diagram below outlines a typical dev box testing flow. The key point to understand is that after the developer initially writes the code, the flow moves into an iterative cycle, between having the code dev box tested and the developer on the back of that coding any changes. This cycle repeats until the BA and tester are happy with the change made and the code can be committed to source control.



Dev box testing strongly encourages collaboration between the BA, developer and tester because it forces conversation, which is key to the success of successful software projects. It is important to point out that dev box testing is not about performing a full regression test, but more of a sanity check to ensure no obvious errors get deployed.

Dev box testing is a great tool in the agile armoury that every team should employ. Any technique that aims to reduce bugs that are committed into source control, and actively encourages collaboration between team members has to be a good thing. There is no reason why you can’t start today!

The post agile techniques – Dev Box Testing appeared first on DEV SCRUM .NET.

]]> http://blog.devscrum.net/2012/03/dev-box-testing/feed/ 4 http://blog.devscrum.net/2012/01/running-a-retrospective/ http://blog.devscrum.net/2012/01/running-a-retrospective/#comments Wed, 18 Jan 2012 19:10:58 +0000 Andrew Jutton http://blog.devscrum.net/?p=397 A retrospective is one of the key practices that any agile team should employ. A retrospective provides an opportunity to bring a team together and collaboratively look back at events that have already taken place. This provides a forum to … Continue reading →

The post Running a Retrospective appeared first on DEV SCRUM .NET.

]]> A retrospective is one of the key practices that any agile team should employ. A retrospective provides an opportunity to bring a team together and collaboratively look back at events that have already taken place. This provides a forum to review events and learn from the experience with the goal of improving the way we work as individuals and a team.

The remainder of this post offers a guideline for how to run a retrospective within your own team.

What do you need

• Someone to act as an mediator to facilitate the session
• The whole scrum team
• Many post its and a pen each
• A strong drink, (I mean coffee!)

Step 1: Prime Directive
Now this step may seem daft, but it is important to ensure that a retrospective is a team sport. It is not about highlighting a mistake an individual has made, but more mistakes a team has made. At the start of each retrospective the mediator should read out the following text.

“Regardless of what we discover today, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available and the situation at hand.”

The mediator should ask everyone if they agree to the above statement. If anyone says no you should not continue.

Step 2: Brainstorming
This is the core part of any retrospective. Start by creating three separate sections on a wall, which I am going to refer to as swim lanes. Take three post it notes and write the one of the following three headers on each one.

• What went well
• What didn’t go well
• What you would like more of and could be improved

Stick this as the heading of each swim lane.

Now lets get everyone involved. the idea is simple, give everyone in the room some post it notes, and ask everyone to write down as many things they can think of it that are of importance to them, for each of the headers we just created. Give everyone about five minutes to write down there ideas and add to the wall.

Step 3: Identifying Common Themes
At the end of step 2, you will have a lot of post it notes within each swim lane. It is almost certain that more than one individual will have raised the same point. In order to make sense of the results, it is best to identify common themes raised within the post it notes by performin the following:

• Within each swim lane, group together all post its that are similar, i.e. you have more than one relating to training.
• Give each group a name, which categorises the post its within.

By performing this step you will suddenly have surfaced clear visibility of the common themes raised by the team.

Step 4: Voting
Having identified a number of groups, it is time to identify the priority to which the team view them. Give each person within the retrospective a number of votes, lets use five votes as a guideline. Then ask all participants to vote on which category they believe is the most important to be raised for further discussion so that it can improved. Votes are not constrained to a single category, in fact votes can be distributed across categories anyway they like. For example all five votes can be used on a single category, or two votes can be used on one category and the remaining three votes could be spread across another three categories.

At the end of the voting step, add the votes together for each category. You now have a priority order of which categories need to be addressed first.

Step 5: Time boxed discussion
Typically within a retrospective I would pick the five categories with the most votes. Then I would allocate a time to spend talking about each one, for example, 12 minutes. This is the real meat of the retrospective, I would typically start by rereading all the post its under the category and then open it up to the floor to discuss as a group. The mediator role here is to ensure the conversation remains on topic and ensures that the time allocated to each category does not overrun.

Step 6: Assign owner to each group to action
The whole point of the retrospective is to address the issues that are of most concern. At the end of each timeboxed discussion, an action should be agreed of how to take the issue forward, whether it be a follow up meeting, or a chat to the CEO, etc Typically I would assign each category an owner. The owner is responsible for taking the action away to address. The same owner can be assigned more than one category.

Step 7: Retrospective Summary
After the retrospective, the mediator is responsible for creating a quick summary, commonly in the form of an email highlighting the top categories that were raised, and the actions that was agreed to take forward.

Conclusion
Retrospectives should occur at the end of every sprint within a scrum project. For any team that wants to continually improve and learn from mistakes a retrospective is an invaluable weapon within an agile armory.

The post Running a Retrospective appeared first on DEV SCRUM .NET.

]]> http://blog.devscrum.net/2012/01/running-a-retrospective/feed/ 1 http://blog.devscrum.net/2011/12/getting-started-with-signalr-in-asp-net-mvc/ http://blog.devscrum.net/2011/12/getting-started-with-signalr-in-asp-net-mvc/#comments Sun, 11 Dec 2011 14:20:28 +0000 Andrew Jutton http://blog.devscrum.net/?p=334 The publish / subscription pattern is a messaging pattern where messages are broadcast by a publisher and are pushed to a variable number of subscribers who have subscribed to the service. The pattern provides loose coupling by disconnecting the publishers … Continue reading →

The post Getting started with SignalR in ASP.NET MVC appeared first on DEV SCRUM .NET.

]]> The publish / subscription pattern is a messaging pattern where messages are broadcast by a publisher and are pushed to a variable number of subscribers who have subscribed to the service. The pattern provides loose coupling by disconnecting the publishers from its subscribers commonly over the form of a queue.

SignalR is an asynchronous signalling library for ASP.NET which provides a framework for broadcasting messages to multiple clients when a given operation on the server is executed, providing a publish / subscription model with the subscribers being either a .NET client application or a web page. SignalR can be used to keep a number of web clients in sync with each other at real time with data held on the server. SignalR achieves this by holding open both the client and server side connections, ensuring the connection always stays open. When a message is sent from a client to the server the server side operation can broadcast a response to all clients by sending a callback to all the open client connections.

SignalR provides a far more efficient solution than simply making a client continuously poll the server on a set timer to check for any change to the state held on the the server and keep itself in sync. SignalR provides an architecture for pushing messages to listening clients rather than having each client individually responsible for pulling messages from the server. This can dramatically reduce the load on the server ensuring there are no needless requests repeatedly being sent from clients.

The real beauty of SignalR is in its simplicity. Requests are sent direct from a web view using JavaScript to the server, and responses are received via a callback on an open connection. This means that SignalR can be used with frameworks such as Knockout.js for easily keeping the UI refreshed with the latest data.

I am sure you can already think of a number of situations where this can be very useful. Such examples could include either an online chat application or a real time booking system. However I found that SignalR was the answer to a problem I had been looking to solve for a while. I am currently working on a large web based integration project for placing insurance quotes online. For a single request that is submitted for a quote, that request can be sent to multiple third party endpoints for processing. All requests are sent asynchronously from the client to the server. Within the application I have a health check routine, which monitors the status of these endpoints. I want to use SignalR to broadcast a message informing the user of the status of a given service within a footer on the application. This will inform the customer who may be waiting on an insurance quote if a service ever goes offline. This will also be very useful during development.

Lets walk through how this could be accomplished by creating a server side endpoint that will be responsible for receiving a request from a client, change a data object and then be responsible for issuing a response with that change to multiple clients.

First create a new ASP.NET MVC 3 web application. To add SignalR to this solution you can issue the following NuGet command in the package manager console within Visual Studio.

Install-Package SignalR

This will download and add the following scripts to your solution.

• Scripts/jquery-1.6.4.js
• Scripts/jquery.signalR.js

plus minimised versions of both scripts.

It will also add a assembly reference to SignalR.dll in your project

There are two options for implementing SignalR server-side. Both options involve deriving a class from an object within the SignalR framework. The two options are persistent connections and hubs. So what is the difference I hear you ask? Well let’s take a quick look at both.

A persistent connection endpoint is exposed as an IHttpHandler. This allows the endpoint to be accessed over HTTP, however in order to do so you must add a custom route map into the route map collection within the web applications global.asax. Deriving from a PersistentConnection enables the ability to override a number of set operations within the SignalR framework to receive client requests and broadcast responses.

The other option is to use a hub. A hub provides the ability to send different types of messages between client and server. There is no need to create a custom route map when using hubs. All requests are routed through the /signalr/hubs route which is added by the SignalR framework to access the hubs. Hubs allow you to add any operations you like. In this example we are going to use Hubs.

The code below is a simple implementation of a hub, with two methods GetServiceState() and UpdateServiceState(), both of which are exposed over HTTP and can be called direct from JavaScript running in a browser. The code includes a static member variable called messages. This is a list of strings and it is static so that its state can be shared across all client instances. The intention of the first method GetServiceState is set the initial state on the client. It is called when the client first opens a connection to the hub. The single line of the method uses the Clients object, which is a dynamic object which represents all the connected clients. As this object is dynamic you can simply specify the name of the callback routine that the JavaScript clients will be listening on. This single line allows you to push the messages collection to all connected clients. The second method UpdateServiceState adds an item to the list and pushes it out to all clients. In this example the current date and time is added to the list.

public class HealthCheck : Hub
{
    public static List<string> messages = new List<string>();

    public void GetServiceState()
    {
        Clients.updateMessages(messages);
    }

    public void UpdateServiceState()
    {
        messages.Add(DateTime.Now.ToString("dd/MM/yyyy HH:mm:ss"));

        Clients.updateMessages(messages);
    }
}

So now to set up the client. In the _Layout,cshtml within your MVC 3 project add a script reference to the SignalR JavaScript library that was downloaded and added to the scripts folder when SignalR was added to the solution with NuGet. Please note that SignalR requires jquery to also be enabled. Therefore you will need to add the following two references.

<script src="@Url.Content("~/Scripts/jquery-1.6.4.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/jquery.signalr.min.js")" type="text/javascript"></script>

In index.cshtml add the following code

<script src="/signalr/hubs" type="text/javascript"></script>
<script type="text/javascript">
    $(function () {
        // creates a proxy to the health check hub
        var healthCheckHub = $.connection.healthCheck;

        // handles the callback sent from the server
        healthCheckHub.updateMessages = function (data) {
            $("li").remove();

            $.each(data, function () {
                $('#messages').append('<li>' + this + '</li>');
            });
        };

        $("#trigger").click(function () {
            healthCheckHub.updateServiceState();
        });

        // Start the connection and request current state
        $.connection.hub.start(function () {
            healthCheckHub.getServiceState();
        });
    });
</script>

<ul id="messages"></ul>

<button type="button" id="trigger">Send request</button>

The code above creates a proxy reference to the health check hub, it registers a callback called updateMessages. This callback is the one that the dynamic Clients object makes reference to and broadcast messages on. An event handler is added for the button. This will call the UpdateServiceState method on the hub when the button is clicked. Finally a connection to the hub is made and the GetServiceState method is called to retrieve the initial server state when the page is first rendered.

To test open two browser tabs and navigate to the view in both. Now click on the Send request button in one of the tabs and you will find that the current date and time is displayed shortly afterwards. Now flip to the other tab and you’ll see that the date and time displayed in the first tab is also displayed. This is because when you clicked the button in the first tab, the hub was called, the current date and time was added to the messages collection and this collection was pushed out to all listening clients who have an open connection registered, in this case both of the tabs.

So this is pretty clever but not a very useful example, but none the less it shows demonstrates a lot of the required plumbing, as we have made a connection to the hub and have registered a callback so that when a message is added on the hub it can be picked up and displayed by any listening clients with an open connection.

As previously mentioned I have a server side process that periodically checks the status of a given set of services. To broadcast the latest status I need to broadcast a message to the clients from outside the hub.

SignalR provides exactly this functionality by allowing you to retrieve the currently connected clients for a given hub by calling Hub.GetClients where T is the hub you wish to retrieve the clients for.

public class HealthMonitor
{
    public void Check()
    {
        /*
         * code ommited for clarity, 
         * but some process running on say a timer
         * or scheduler returns the latest state of the 
         * services and updates the messages
         * property on the HealthCheck hub
         */

        dynamic clients = Hub.GetClients<HealthCheck>();
        clients.updateMessages(HealthCheck.Messages);
    }
}

The code above is a arbitrary piece of code which can be run on the server. It can however also broadcast a message to all the currently connected clients outside of the hub itself. The other code change I made was to change the messages field variable to a property so I can keep the same list in sync whether it is updated from a client or server request.

public class HealthCheck : Hub
{
    private static List<string> messages;

    public static List<String> Messages 
    { 
        get
        {
            if (messages == null)
            {
                messages = new List<string>();
            }

            return messages;
        }
        set
        {
           messages = value;
        }
    }

//remaining code ommited

Each request that is received within the hub also includes the callers context. This can be used to only broadcast a response to a specific client. SignalR also provides the functionality to alternatively broadcast a response to a group of subscribers.

It is worth pointing out that the client is not restricted to being an MVC view, it can also be a .NET client.

SignalR is open source framework hosted on github. I would strongly recommend having a look at the documentation on the github site.

The post Getting started with SignalR in ASP.NET MVC appeared first on DEV SCRUM .NET.

]]> http://blog.devscrum.net/2011/12/getting-started-with-signalr-in-asp-net-mvc/feed/ 2