3 Rules for TDD

I couldn’t help but share this. There couldn’t be a better way to summarize the unwritten rules of TDD, than the one wrote by Uncle Bob in his famous book ‘Agile Principles, Patterns and Practices in C#”.

  • Don’t write any production code until you have written a failing unit test.
  • Don’t write more of a unit test than is sufficient to fail or fail to compile.
  • Don’t write any more production code than is sufficient to pass the failing test.

What it emphasises is when to switch between writing Unit Test and Production code, a key point, atleast according to me, for many times I see developers who try to think and build way too many test cases than what is actually needed. Honestly, yours truly too has been guilty of so called BDUF for Unit Test.

Uncle Bob, in formulating the 3 basic rules, emphasis that one needn’t write a unit test no more than when it fails or fails to compile, after which the developer proceeds to write the minimum code required to pass the test case. This short cycles would help the developer adopt the TDD approach in a better way.

Thanks Uncle Bob.

Revisting Anonymous Type

While classes and structs are extremely powerful, there are times when you want to escape the cermonies they require even for simplest of design. This is where anonymous types comes handy and has been so frequent used by the developers.

So what are Anonymous types really ? Let’s consider an example first.

var point = new {X = 20, Y = 30}

Anonymous Types are compiler generated immutable reference type.

Though framed in few words, that definition probably describes a lot more than that meets the eye. From the point of definition of our anonymous type above, it means you are directing the compiler to generate an internal sealed class, which has two read-only properties namely X and Y. For example, the compiler might generate something similiar to following class for the anonymous type we just declared.

internal sealed class Point
{
private int _x;
private int _y;

public int X => _x;
public int Y => _y;

public Point(int x,int y)
{
_x = x;
_y = y;
}
}

Do notice this might not be exactly what compiler generates. There could be certain things which you cannot do yourself, but the above example kind of provides the gist.

The Anonymous Type syntax allows you to do all that declaration with very little need to type them yourself. This eliminates the chances of human error, in addition to saving your time as well as polluting the application namespace. The scope of the defined anonymous type is restricted to the method it is defined.

But, Anonymous Types has their drawbacks as well. As a developer, you do not know the Type. Imagine, you need to pass the anonymous type to a method, how would you do it ? Tricky, isn’t it.

If you do not have to individually process different properties of the Anonymous types, you can achieve this using Generic methods. For example, you can use following method to compare two anonymous types.

bool IsEqual<T>(T source, T itemToCompare)
{
return source.Equals(itemToCompare);
}
// Client Code
var point1 = new {X = 20, Y = 45};
var point2 = new {X = 20, Y = 45};

var comparisonResult = IsEqual(point1,point2);

But what if you need to process the individual properties of Anonymous types within the method ? For example, you want to increment the X and Y of Point by 1 (let’s ignore reflection for the moment)

One way to achieve this would be use Generic methods with Func parameters. For example,

T Execute<T>(T source, Func<T,T> incrementFunction)
{
return incrementFunction(source);
}

You can invoke the method as the following.

var result = Execute(point,(p)=> new {X=p.X + 1, Y=p.Y+1});

Let’s now explore another possibility. Consider a method that returns an anonymous type.

object GetPoint()
{
return new {X = 20, Y = 45};
}

How would one process the individual properties in the caller method ? Surely, following would fail to compile

// Following would fail to compile
var point = GetPoint();
var x= point.X;

Deconstruction won’t be a help either as anonymous types doesnt support it.

// Following would fail to compile
var (x,y) = GetPoint();

What we would require it to cast the returned object to anonymous type, that resembles the original. Let us write a quick extension method it.

public static class Extensions
{
public static T Cast<T>(this object source,T sampleType)
{
return (T)source;
}
}

Now you can use the return type by casting it to desired Anonymous Type and use it in your rest of code.

var point = GetPoint();
var result = point.Cast(new{X=default(int),Y=default(int)});
Console.WriteLine($"X={result.X},Y={result.Y}");

That’s it for now, Happy Coding.

Zoom Rectangle with OxyPlot

Let’s stick to OxyPlot for some more time. This time, we would attempt to change the color of Zoom Rectangle. For those who are new to Oxyplot, the control allows you to zoom in a particular location by permitting the user to draw rectangles in the graph. This particular rectangle is known as Zoom Rectangle.

You can enable the Zoom Rectangle by using the PlotController.

public PlotController ChartController { get; set; }

ChartController = new PlotController();
ChartController.BindMouseDown(OxyMouseButton.Left, PlotCommands.ZoomRectangle);

You can now bind the PlotController with your OxyPlot PlotView instance in XAML.

<oxy:PlotView Model="{Binding Model}" Controller="{Binding ChartController,UpdateSourceTrigger=PropertyChanged}"/>

While would enable the Zoom Rectangle, you would ideally would like to do a bit of Customization, for example, changing the appearance(color) of the rectangle.

You can do so by customizing the ZoomRectangleTemplate. Let’s change the default color of the Zoom Rectangle we just created.

<oxy:PlotView Model="{Binding Model}" Controller="{Binding ChartController,UpdateSourceTrigger=PropertyChanged}">
<oxy:PlotView.ZoomRectangleTemplate>
<ControlTemplate>
<Border BorderBrush="Black" BorderThickness="1">
<Rectangle Fill="Orange" />
</Border>
</ControlTemplate>
</oxy:PlotView.ZoomRectangleTemplate>
</oxy:PlotView>

That’s all you need. You now have your fully customized Zoom Rectangle.

Oxyplot

Caliburn.Micro Template Pack now supports VS 2019

So glad to announce that Caliburn.Micro Template Pack now supports Visual Studio 2019.

Caliburn.Micro Template Pack for WPF contains a comprehensive collection of Project Templates and Code Snippets for developing WPF application using Caliburn.Micro. It also includes Bootstrap templates for SimpleContainer, MEF and Unity.

You can download the template from Visual Studio Marketplace

You can read more on the template here

Oxyplot : Using Datagrid for tooltip

Oxyplot uses Tracker Controls for displaying tooltip. You could extend the display by Customizing the Default Tracker control. In this article, we will look deeper into that Tracker Control and aim to display a Grid in the Tracker Control.

For sake of example, let us assume a Fruit Seller, who wants to plot his sales per day on a Line Series. To begin with, let us create some random data to emulate the sales.

private enum eFruits
{
Apple,
Banana,
Mango,
Jackfruit
}
public IEnumerable<Fruit> Generate()
{
var random = new Random();
return Enumerable.Range(1, 10)
.SelectMany(x =>
{
return ((eFruits[])Enum.GetValues(typeof(eFruits))).Select(f =>
new Fruit
{
Name = f.ToString(),
ItemsSold = random.Next(0, 100),
Date = DateTime.Now.AddDays(x)
});
});
}

In his first attempt, he plots the Line Series, grouping the data by Date on which items where sold.

private void CreatePlotModel(IEnumerable<Fruit> totalSalesDetails)
{
var salesGrouping = totalSalesDetails.GroupBy(x => x.Date);
var yAxis = new LinearAxis
{
Position = AxisPosition.Left
};
var xAxis = new DateTimeAxis
{
Position = AxisPosition.Bottom,
Minimum = DateTimeAxis.ToDouble(salesGrouping.Min(x => x.Key)),
Maximum = DateTimeAxis.ToDouble(salesGrouping.Max(x => x.Key)),
};
DataPlotModel.Axes.Add(yAxis);
DataPlotModel.Axes.Add(xAxis);

var lineSeries = new LineSeries
{
MarkerFill = OxyColors.Blue,
MarkerType = MarkerType.Circle,
TrackerFormatString = "{0}\n{1}: {2:dd.MM.yy}\n{3}: {4:0.###}"
};
lineSeries.Points.AddRange(salesGrouping.Select(x => new DataPoint(DateTimeAxis.ToDouble(x.Key), x.Sum(c => c.ItemsSold))));
DataPlotModel.Series.Add(lineSeries);
}

XAML Part

<oxy:PlotView Model="{Binding DataPlotModel}"/>

This gave him his desired out as the following.

Initial Design

However, this left a lot to be desired. Currently the tooltip would display total sales per day. He knew he could decifer that from the chart itself and hence wanted to make use of tooltip for something more useful. He decided to display the details of sales, ie, number of each fruit sold during the day in the tooltip. This would give him a better insight into the sales.

Grid inside the Tooltip

While he knew the Oxyplot’s default Tracker control could be customized, he soon realized this wasn’t as straightward as he assumed it to be. As always, the problem lies in the details.

<oxy:PlotView Model="{Binding DataPlotModel}">
<oxy:PlotView.DefaultTrackerTemplate>
<ControlTemplate>
<oxy:TrackerControl>
<DataGrid ItemsSource="{Binding}"/>
</oxy:TrackerControl>
</ControlTemplate>
</oxy:PlotView.DefaultTrackerTemplate>
</oxy:PlotView>

The TrackerControl accepted a TrackerHitResult as its DataContext, displaying the TrackerHitResult.Text as tooltip, and there seemed no direct way for him to bind a collection of items to the TrackerControl if he was to customize it to include a DataGrid.

A bit of googling and with a tip from his mentor, he soon realized that there was a way instead. What if he can write a Converter that reads the required information from TrackerHitResult and returns a collection for DataGrid to bind to.

For this, he needs to extend the DataPoint so that it would contain the sub-collection information. This would ensure that the same would be available in the DataContext (TrackerHitResult)

public class ExtendedDataPoint : IDataPointProvider
{
public DateTime Date { get; set; }
public IEnumerable<Fruit> ItemsSold { get; set; }

public DataPoint GetDataPoint()
{
return new DataPoint(DateTimeAxis.ToDouble(Date), ItemsSold.Sum(x=>x.ItemsSold));
}
}

He can now rewrite his CreatePlotModel method to use the ExtendedDataPoint for adding points to the Line Series.

var lineSeries = new LineSeries
{
MarkerFill = OxyColors.Blue,
MarkerType = MarkerType.Circle,
};

lineSeries.ItemsSource = salesGrouping.Select(x => new ExtendedDataPoint
{
Date = x.Key.Date,
ItemsSold = x.ToList()
});

As you can notice, he has removed the TrackerFormatString as well, as he would not require it any longer. The next step would be to write the Converter required for transforming the TrackerHitResult to IEnumerable<Fruit>.

public class TrackerHitResultConverter : IValueConverter
{
public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
{
if(value is TrackerHitResult data)
{
return (data.Item as ExtendedDataPoint).ItemsSold;
}
return null;
}

public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
{
throw new NotImplementedException();
}
}

Since he had already defined his required sub-collection as a part of ExtendedDataPoint, the role of TrackerHitResultConverter became a lot easier. The last piece in the puzzle was to modify the Xaml to use the Converter.

<oxy:PlotView Model="{Binding DataPlotModel}">
<oxy:PlotView.DefaultTrackerTemplate>
<ControlTemplate>
<oxy:TrackerControl Position="{Binding Position}" Background="Transparent" BorderBrush="Transparent">
<DataGrid HeadersVisibility="None" ItemsSource="{Binding Converter={StaticResource TrackerHitResultConverter}}" AutoGenerateColumns="False" CanUserAddRows="False" CanUserDeleteRows="False">
<DataGrid.Columns>
<DataGridTextColumn Binding="{Binding Date,StringFormat=d}" Header="Date" />
<DataGridTextColumn Binding="{Binding Name}" Header="Fruit"/>
<DataGridTextColumn Binding="{Binding ItemsSold}" Header="Items Sold" />
</DataGrid.Columns>
</DataGrid>
</oxy:TrackerControl>
</ControlTemplate>
</oxy:PlotView.DefaultTrackerTemplate>
</oxy:PlotView>

With that in place, he was ready to Hit F5 and vola, his tooltip was ready.

Final output

Entire source code discussed in this article is available in my Github.

Law Of Demeter

If you ask any Software Developer, he would vouch that separation of concerns is the fundamental principles for maintaining any complex system and one of the vital links for achieving Separation of Concerns is decoupling.

Law of Demeter (LoD), also known as Principle of least knowledge, intends to reduce coupling between objects as proposed by Ian Holland.

Definition

The original version is outlined as follows.

Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.

The gist of the definition lies in the simple fact that the class should speak only to objects that it directly knows, or in other words, do not talk to strangers.

Let’s examine a real life scenario. You are out to stroll with your favourite pet. You do not order your pet’s legs to walk. Instead, you order your pet, which inturns commands its legs to move.

If we were to examine the rule from the perspective of an Object Oriented Programming Language,

A Method M, of an Object of Type C, may only call methods of
a) Class C
b) Parameters of method M
c) Instance variables of C
d) Objects created by M
e) Global Variables

Let’s write some code to replicate the Pet Scenario we discussed earlier.

public class Owner:IHuman,IHasPet
{
public string Name{get;set;}
public Pet Pet{get;set;}
public void MovePet()
{
Pet.GetLegs().Move();
}
}

public class Pet
{
private Legs _legs;
public Legs GetLegs ( )=>_legs;
}

public class Legs
{
public void Move()
{

}
}

As observed, the Owner Class uses instance of Pet to retrieve instance of Legs, and then request them to move.But, there is no reason the owner needs to be have access or knowledge of the legs or how the Pet commands the legs to move. This is the responsibility of the Pet class and should not be exposed the owner class.

In the above scenario, the Owner class has knowledge of something, which it doesn’t instantiate or should knowledge of and is a clear violation of Law of Demeter.

We can rewrite the classes to overcome the problem.

public class Owner:IHuman,IHasPets
{
public string Name{get;set;}
public Pet Pet{get;set;}
public void MovePet()
{
Pets.Move();
}
}

public class Pet
{
private Legs _legs;
public void Move()
{
_legs.Move();
}
}

In fact, if you look back at Gang Of Four patterns, many of the patterns discretely follows the Law Of Demeter.

A Word of Caution.

While the benefits of following the rule is evident, one also needs to be beware of focusing way too much on adherence to the rule, rather than fulfilling the purpose of the rule, which is to reduce coupling.

Json Custom Filtering : Remove Properties of a Type T

One of the recent questions that came up in SO which fascinated me was how do one filter a Json string by removing properties from Json, which is of a particular Type. For example, consider the following Json.

{
'widget':
{
'debug': 'on',
'window': {
'title': 'Sample Widget',
'name': 'main_window',
'width': 500,
'height': 500
},
'image': {
'src': 'Images/Sun.png',
'name': 'sun1',
'hOffset': 250,
'vOffset': 250,
'alignment': 'center'
},
'text': {
'data': 'Click Here',
'size': 36,
'style': 'bold',
'name': 'text1',
'hOffset': 250,
'vOffset': 100,
'alignment': 'center',

}
}}

What if you want to remove all Json Properties that has a value of Integer Type. What would be a good way to achieve it if the format of Json is unknown ?

I ended up writing an extension method.

public static class Extensions
{
public static JToken RemoveFieldTypes(this JToken token,params JTokenType []fieldTypes)
{
JContainer container = token as JContainer;
if (container == null) return token;

var tokensToRemove = new List<JToken>();
foreach (JToken el in container.Children())
{
JProperty p = el as JProperty;
if(p!=null && fieldTypes.Contains(p.Value.Type))
{
tokensToRemove.Add(el);
}
el.RemoveFieldTypes(fieldTypes);
}
foreach (JToken el in tokensToRemove)
{
el.Remove();
}
return token;
}
}

Client Code Sample

JToken nodeList = JToken.Parse(strJson);
nodeList.RemoveFieldTypes(JTokenType.Integer);

Sample Ouput

{
"widget": {
"debug": "on",
"window": {
"title": "Sample Konfabulator Widget",
"name": "main_window"
},
"image": {
"src": "Images/Sun.png",
"name": "sun1",
"alignment": "center"
},
"text": {
"data": "Click Here",
"style": "bold",
"name": "text1",
"alignment": "center"
}
}
}