Integration Tests – Tests Fail When Network Unavailable
I code a lot whilst travelling to work on the train. One thing that has bugged me is integration tests that rely on remote services will fail unless I’ve tethered my phone. Having those few red tests littering my test results kind of irks me and leads me to run the tests less often or not at all.
What I wanted was an ignore attribute that could detect if the network was unavailable and ignore the test, but I couldn’t find anythign to suit. As there isn’t great support for extending test attributes, I decided to build support in to my IntergrationBaseTest class.
This could have been solved easily by placing these two lines at the start of my test:
if(!NetworkInterface.GetIsNetworkAvailable())
Assert.Inconclusive();
The above is simple but I wanted to explore the idea of custom test attributes to see what I could come up with.
What first sprang to mind was ASP.NET MVC’s ActionFilterAttributes. MSDN describes ActionFilterAttributes as the following:
ActionFilterAttribute is an abstract class that has four virtual methods that you can override: OnActionExecuting, OnActionExecuted, OnResultExecuting, and OnResultExecuted.
The ASP.NET MVC framework will call the OnActionExecuting method of your action filter before it calls any action method that is marked with your action filter attribute. Similarly, the framework will call the OnActionExecuted method after the action method has finished.
Taking this approach and applying it to MSTest I created the below abstract attribute:
public abstract class CustomTestAttribute : Attribute
{
public virtual void OnTestExecuting(TestContext context) {}
public virtual void OnTestExecuted(TestContext context) {}
}
I marked the methods as virtual so as not to force derived classes to implement both. As you might have guessed the OnTestExecuting maps to methods marked with the TestInitializeAttribute and the OnTestExecuted maps to the TestCleanupAttribute in MSTest. The benefit we gain here is the ability to descriminate down to the method level within a class.
To support the new attribute the base class is going to have to know about it and execute the respective methods in the corresponding initialize and cleanup methods.
First, to deal with multiple attributes as a single unit, I created a CompositeTestAttribute, deriving form the CustomTestAttribute:
public sealed class CompositeTestAttribute : CustomTestAttribute
{
private readonly IEnumerable<CustomTestAttribute> attributes;
public CompositeTestAttribute(IEnumerable<CustomTestAttribute> attributes)
{
this.attributes = attributes;
}
public override void OnTestExecuting(TestContext context)
{
foreach (var customTestAttribute in attributes)
{
customTestAttribute.OnTestExecuting(context);
}
}
public override void OnTestExecuted(TestContext context)
{
foreach (var customTestAttribute in attributes)
{
customTestAttribute.OnTestExecuting(context);
}
}
}
To determine which attributes the executing test is decorated with we can use the TestContext which gets injected by mstest at runtime, all you need to do is dangle a property on the base class:
public TestContext TestContext { get; set; }
Using the TestContext we can access the “FullyQualifiedTestClassName” and “TestName” properties. This gives us enough information to generate a type and access the attributes:
private IEnumerable<CustomTestAttribute> GetCustomTestAttributes()
{
IEnumerable<CustomTestAttribute> attributes = Enumerable.Empty<CustomTestAttribute>();
string className = TestContext.FullyQualifiedTestClassName;
string methodName = TestContext.TestName;
Type testClassType = Type.GetType(className);
if (testClassType != null)
{
MemberInfo mi = testClassType.GetMethod(methodName);
attributes = mi.GetCustomAttributes<CustomTestAttribute>();
}
return attributes;
}
All that’s needed now is to invoke OnTestExecuting and OnTestExecuted in the TestInitialize and TestCleanup methods respectively.
[TestInitialize()]
public void MyTestInitialize()
{
new CompositeTestAttribute(GetCustomTestAttributes())
.OnTestExecuting(this.TestContext);
}
[TestCleanup()]
public void MyTestCleanup()
{
new CompositeTestAttribute(GetCustomTestAttributes())
.OnTestExecuted(this.TestContext);
}
Now, that the infrastucture is there, we can start implementing CustomTestAttributes. Which brings me back to the reason for all this.
To determine if the Network is available, there is a handy helper method located in “System.Net.NetworkInformation.NetworkInterface” called
“GetIsNetworkAvailable()”
public class IgnoreWhenNetworkUnavailableAttribute : CustomTestAttribute
{
public override void OnTestExecuting(TestContext context)
{
if(!NetworkInterface.GetIsNetworkAvailable())
Assert.Inconclusive();
}
}
Now to make use of this, all we have todo is derive from the IntegrationBaseTest and decorate our network dependent test methods.
For clarity, below is the full code. Although this could have been achieved by far simpler means, it was an interesting exercise, that allowed me to delve into some code and have a little fun. I hope you find this helpful and put CustomTestAttributes to use in scenarios I haven’t thought of.
/// <summary>
/// Summary description for IntegrationTestBase
/// </summary>
[TestClass]
public class IntegrationTestBase
{
public TestContext TestContext { get; set; }
[TestInitialize()]
public void MyTestInitialize()
{
new CompositeTestAttribute(GetCustomTestAttributes())
.OnTestExecuting(this.TestContext);
}
[TestCleanup()]
public void MyTestCleanup()
{
new CompositeTestAttribute(GetCustomTestAttributes())
.OnTestExecuted(this.TestContext);
}
private IEnumerable<CustomTestAttribute> GetCustomTestAttributes()
{
IEnumerable<CustomTestAttribute> attributes = Enumerable.Empty<CustomTestAttribute>();
string className = TestContext.FullyQualifiedTestClassName;
string methodName = TestContext.TestName;
Type testClassType = Type.GetType(className);
if (testClassType != null)
{
MemberInfo mi = testClassType.GetMethod(methodName);
attributes = mi.GetCustomAttributes<CustomTestAttribute>();
}
return attributes;
}
}
public class IgnoreWhenNetworkUnavailableAttribute : CustomTestAttribute
{
public override void OnTestExecuting(TestContext context)
{
if(!NetworkInterface.GetIsNetworkAvailable())
Assert.Inconclusive();
}
}
public abstract class CustomTestAttribute : Attribute
{
public virtual void OnTestExecuting(TestContext context) {}
public virtual void OnTestExecuted(TestContext context) {}
}
public sealed class CompositeTestAttribute : CustomTestAttribute
{
private readonly IEnumerable<CustomTestAttribute> attributes;
public CompositeTestAttribute(IEnumerable<CustomTestAttribute> attributes)
{
this.attributes = attributes;
}
public override void OnTestExecuting(TestContext context)
{
foreach (var customTestAttribute in attributes)
{
customTestAttribute.OnTestExecuting(context);
}
}
public override void OnTestExecuted(TestContext context)
{
foreach (var customTestAttribute in attributes)
{
customTestAttribute.OnTestExecuting(context);
}
}
}
MVC 4 Beta Project Templates – Visual Studio Freezes on Adding Script tags to view
I’ve been playing around with the new WebApi that was released with MVC 4 Beta and have come across what seems like a bug.
So far I’ve been able to reproduce this consistently on two separate machines.
The issue occurs when adding script tags to a view, it seems that visual studio hangs for at least 30 seconds.
Has anyone else been playing with the WebApi and noticing this issue?
UPDATE: this seems to happen in any MVC 4 project template and, in particular, when hitting the carriage return.
ASP.NET MVC 4 Beta Released
Top Features
ASP.NET Web API
Refreshed and modernized default project templates
New mobile project template
Many new features to support mobile apps
Recipes to customize code generation
Enhanced support for asynchronous methods
Read the full feature list in the release notes
Extracting the Func
Recently, I’ve found myself using Generic Delegates quite a lot, and in particular the Func<> delegate. Delegates can be a great way of reducing duplication and increasing code re-use.
The following is a rather contrived example, and mostly useless, but it helps to illustrate the process of what I like to call “Extracting the Func”
Say you have a method that writes to the console, the result of adding two numbers together:
public void WriteResultOfCalculation(int x, int y)
{
Console.Write((x + y).ToString());
}
But then, u decide you want similar functionality, but instead of adding x and y you want to multiply x and y (besides obvious ways of doing this) you could extract the calculation into a Func delegate like this:
public void WriteResultOf(Func<int, int, string> calculation)
{
Console.Write(calculation);
}
WriteResultOf((x,y) => (1 * 2));
Here we have pushed the responsibility of performing the calculation to the consumer. This code is quite useless, but I’ve intentionally used this example so not to distract from the point.
The next example of this pattern, hopefully, shows how this can be useful. A few weeks ago, I was working with a repeater control in an asp.net site. The repeater contained a usercontrol with multiple grids and I needed easy access to manipulate every instance of this usercontrol in the repeater. So I whipped up a quick extension method for Repeater controls modeled on the IList ForEach extension:
public static void ForEach<TControl>(this Repeater repeater, Action<TControl> action) where TControl : Control
{
foreach (RepeaterItem item in repeater.Items)
{
foreach (Control control in item.Controls)
{
Repeater nestedRepeater = control as Repeater;
if(nestedRepeater != null)
{
nestedRepeater.ForEach(action);
}
TControl t = control as TControl;
if(t != null)
{
action(t);
}
}
}
}
This method has a type parameter of TControl, which is constrained to types derived from “Control”. This is the type of the control that you are wishing to gain access to, within the repeater. It iterates the RepeaterItems of the repeater, and nested in this, it iterates the controls of each RepeaterItem. Within the nested loop, it first performs a safe cast to typeof(Repeater), and performs a recursive call if the cast is successful. Finally, a safe cast is performed to TControl, and if successful it calls the Action delegate, passing in the instance of TControl as the argument.
In a nutshell, it performs recursion to find all instances of the type TContol within the repeaters nested controls, then performs the action, specified by the consumer, on the control.
The signature of Action is a method that accepts a paramter of type TControl and returns void:
void Action(TControl control);
As the ForEach is modelled on ILists ForEach, its usage should be fairly intuitive. For example, lets say the control we are after has a public method “LoadReport”, and we’d like to call this method for each instance inside the repeater, we can call it like this:
repeater.ForEach(control => control.LoadReport());
Piece of cake. Now as I wasn’t happy leaving this nested loop, essentially hiding the intent of code, I’ve refactored it a little, breaking down into 4 smaller methods:
public static void ForEach<T>(this Repeater repeater, Action<T> action) where T : class
{
repeater.ForEachNestedRepeater(action);
foreach (T t in repeater.GetItemsOfType<T>())
{
action(t);
}
}
private static void ForEachNestedRepeater<T>(this Repeater repeater, Action<T> action) where T : class
{
repeater.GetItemsOfType<Repeater>()
.ForEach(r => r.ForEach(action));
}
private static IEnumerable<T> GetItemsOfType<T>(this Repeater repeater)
{
return repeater.Items.Cast<RepeaterItem>()
.Select(item => item.Controls)
.OfType<T>();
}
private static void ForEach(this IEnumerable<Repeater> repeaters, Action<Repeater> action)
{
foreach (var repeater in repeaters)
{
action(repeater);
}
}
Happy coding!
Windows Azure Discovery Day
Just got back from Windows Azure Discovery Day with Graham Elliot. Overall a good day, covering Cloud Computing Scenarios for ISVs, Understanding the Windows Azure Platform Pricing Model, Building Applications for Windows Azure & SQL Azure, then finishing off with a few demo’s.
Useful Azure links:
Windows Azure Developer Training Kit
Get amongst it!
Kentico vs ValidateRequest
It seems Kentico are insisting on not encoding html sent to the server from the fckEditor. Instead, Kentico advises to turn ValidateRequest off.
That’s pretty fckEd. In this post, Kentico assure us they take security seriously;
we do a lot of investigating on this issue and fix every potentially dangerous part of the system during development stage as well as later during testing stage”
It would seem to me that encoding html from the fckEditor, in order to allow ValidateRequest not to break, would be high on their list. Apparently not.
The issue I have is, not all of the website in question is the work of kentico. In fact, the bulk of the solution is custom built, while using Kentico to leverage it’s content management. Obviously then, it would be unwise to turn off ValidateRequest for the whole site.
So enough ranting about Kentico, here’s the solution. Short of hacking the entire Kentico site to htmlencode all instances of the fckEditor, we can localise turning off ValidateRequest just to Kentico pages via directory-level web.configs and keep ValidateRequest = true at the root web.config.
Add this section to Directory level web.configs for all things kentico (ie. CMSAdminControls, CMSDesk, CMSFormControls, CMSMasterPages, CMSModules, CMSPages, CMSSiteManager)
<system.web> <pages ValidateRequest="false" /> </system.web>
Kentico have advised they will look at fixing this issue in later releases. However, I wouldn’t hold your breath, they’ve been saying this since 2006.
So, in short, Kentico are fckEd.
No Quarter?
GetQuarter();
public static int GetQuarter(int month)
{
return month <= 3 ?
1 : ((month >= 4) && (month <= 6) ?
2 : ((month >= 7) && (month <= 9) ?
3 : 4));
}
