Stuff - mainly geek, a little diabetes, some rant. Possibly all three in the same post. Basically anything I find interesting and/or worth sharing.
These are my personal views, unless I've been hacked.
Every now and again a new framework class comes to my attention. At DevWeek I was attending a talk on Cryptography and an incidental part of the talk featured the BitConverter class. This is a class in the System namespace and has a bunch of static methods that convert to and from a byte array.
The ToString(byte[]) method was the one that I saw being used. It takes an array of bytes and converts each byte to its 2 character hexadecimal equivalent. This is an alternative to Base64 encoding and is arguably more human-friendly.
Other methods on the BitConverter class allow you to convert between a byte array and numerical types:
If you have some code that uses configuration from an app.config or web.config file, and you need to retrospectively write tests for it, there are several approaches you can take to get fake setting into your tests.
Given this code
using System; using System.Configuration; using System.IO;
namespace Demo
{ class Program
{ staticvoid Main(string[] args)
{ using (var writer = new StringWriter())
{ new SeasonWriter().WriteSeason(writer);
Console.WriteLine(writer);
Console.ReadLine();
}
}
}
publicclass SeasonWriter
{ publicvoid WriteSeason(TextWriter textWriter)
{ var month = ConfigurationManager.AppSettings["Month"]; switch (month)
{ case"January": case"February": case"December":
textWriter.Write("Winter"); break; case"March": case"April": case"May":
textWriter.Write("Spring"); break; case"June": case"July": case"August":
textWriter.Write("Summer"); break; case"September": case"October": case"November":
textWriter.Write("Autumn"); break; default: thrownew ConfigurationErrorsException("No setting defined for 'Month'."
+ Environment.NewLine
+ "Please add a setting to the .exe.config file under the section AppSettings."
+ Environment.NewLine
+ "For more info on the .exe.config file, follow this link "
+ "http://msdn.microsoft.com/en-us/library/vstudio/1fk1t1t0(v=vs.110).aspx");
}
}
}
}
In order to get tests around the SeasonWriter class, the AppSettings entry "Month" needs to be faked or abstracted. Some options are:
Create an app.config file in the test project
This is the most obvious starting point. Create a test project to contain the SeasonWriterTests file, with an app.config containing a "Month" entry:
namespace Demo.Test
{
[TestFixture] publicclass SeasonWriterTests
{
[Test] publicvoid WriteSeasonExpectWinter()
{ var writer = new StringWriter(); var target = new SeasonWriter();
target.WriteSeason(writer);
Assert.That(writer.ToString(), Is.EqualTo("Winter"));
}
}
}
This will allow the test to run, but will limit you to testing a single path through the code. It's also flaky, because your test depends on a magic string in a separate file.
Pass the configuration setting in
This solution is a refactor of the WriteSeason method, so it takes the config setting in as a string. This sounds like a clean fix, with benefits
the responsibility for getting that value has been handed off to the user of the method
the code is easier to test
However, there are downsides
the refactor is an untested change
there could be many users of this method, and each one would be responsible for getting the month value
the exception type in the WriteSeason method is no longer correct
Set the config value
The easiest way to fake an AppSettings value is just to set it in your test class. ConfigurationManager.AppSettings is just a NameValueCollection, and items can be written as well as read:
using NUnit.Framework; using System.IO; using System.Configuration;
var writer = new StringWriter(); var target = new SeasonWriter();
target.WriteSeason(writer);
Assert.That(writer.ToString(), Is.EqualTo(expectedSeason));
}
}
}
If you're regularly using a block of HTML elements consisting of opening tags and closing tags, you might want to employ the using pattern used by the framework's FormExtensions:
This is pretty straightforward; you need to create a class that implements IDisposable and render the opening tags in the constructor, and the closing tags in the Dispose method.
As an example I'll implement an HtmlHelper extension that renders a multi-column table with a header row containing the column titles specified, that will be rendered like this:
The first step is to create a static class for the extension method, and the extension method itself. This should be an extension method for the HtmlHelper object, and needs to return an instance of a class that implements IDisposable:
The HtmlHelper exposes a ViewContext, which has a Writer property; this is a TextWriter, and it's this object that stores the HTML that will be sent to the HttpResponse. The writer is the object that we need to pass our HTML string to. For this example, I also need the headers to render, so I've added a params parameter to the extension method:
The implementation of the disposable helper constructor builds and writes the table header, and the dispose method writes the closing tag:
The usage of the helper in the view can be changed to this:
This is a follow up post to my previous one on adding tests to legacy code, and shows several techniques for removing a dependency on a call to a static method. Once again, I make no apologies for the state of the resulting code; these techniques are each a pragmatic step towards getting legacy code under test so it can be refactored.
The code to test
The class to write tests for is intentionally simple; it has a single method that takes a string which is used to look up a value in a file, and modifies that string before returning it. Because of the dependency on a file, the code doesn't run from a unit test without that file being present.
The ConfigReader class also has a single method, that reads a value from a custom configuration file:
publicclass ConfigReader
{ publicstaticstring GetConfig(string setting)
{ using (var reader = File.OpenText("..\app.config"))
{ string line; while ((line = reader.ReadLine()) != null)
{ var elements = line.Split('='); if (elements[0] == setting)
{ return elements[1];
}
}
} returnnull;
}
}
Add virtual method
This is the technique that I highlighted in my original post. It involves creating a virtual method in the class under test, which in a production setting will delegate the call to the existing static method. In a test scenario though, it allows the class under test to be subclassed, and override the virtual method to return a dummy result.
Notes
This technique can only be used when the class under test is not sealed
It requires no changes to the static class
Steps to implement:
Class under test
Add a virtual method
Delegate the call to the static method to the new virtual method
Update calls to the static method to call the new method
This technique involves adding an instance method to the dependency class, and extracting its interface. A stub of this interface can then be passed to the class for testing.
Notes
This technique can only be used when the dependency class is not marked static
Steps to implement:
Dependency class
Add an instance method
Delegate from the instance method to static method
//2 var target = new Builder(configFileReader);
Assert.That(target.BuildString(""), Is.EqualTo("xxExpectedxx"));
}
}
Wrap static class
This technique is to create an instance class that delegates calls to the static class, but allows an interface to be specified for the calling class to use.
Notes
This technique does not require any change to the dependency class
Steps to implement:
Wrapper class
Create a new class with an instance method
Delegate from the instance method to the static methods
var target = new Builder();
Assert.That(target.BuildString(""), Is.EqualTo("xxExpectedxx"));
}
}
Any more?
One other technique is to use an advanced mocking framework that can stub static methods; unfortunately none of the free ones I know have this feature.
Can you think of any other techniques that I haven't covered? If so, please leave a comment and let me know.
Imagine you have some legacy code in your product. Code that's been added to over the years by several different developers, none of who were certain they understood the code. There is no separation of concerns; the code has business logic and database access baked in. There's no useful documentation and the code comments are no more than sarcastic outbursts of cynicism.
A bug report has come in that suggests some of the SQL being executed from this method is invalid. So, what's the plan? Hack the SQL construction around until it feels like it does what you want, hoping you haven't broken anything else in the class? Or take a more structured approach?
To illustrate the problem, I have written some legacy-style code so I can show how to refactor it to make it testable. The techniques here are a pragmatic approach to getting legacy code under test, while making as few untested changes as necessary. Because as you will already know, a class is only able to be refactored when it's under test.
The code for the class is available on GitHub here, and looks like this
using System.Collections;
namespace CombinationOfConcerns
{
public class Data
{
private readonly string _type;
public Data(string type)
{
_type = type;
}
public ArrayList GetData(string code, string gdr, string filterType, bool getAge)
{
ArrayList results = null;
var sql = "select id from people where type = " + _type + " and gender ='" + gdr + "'";
string values = DatabaseWrapper.GetSingleResult(sql);
for (int i = 0; i < values.Split(',').Length; i++)
{
switch (code)
{
case "128855":
sql = "select name";
if (getAge)
sql += ",age";
sql += ",gender from people where type in(" + values + ")";
if (filterType == "45")
{
sql += " and gender='" + gdr + "'";
}
if (filterType == "87")
{
sql += " and shoesize = 43";
}
results = DatabaseWrapper.GetManyResults(sql);
break;
case "1493":
sql = "select dogs.name, dogbreeds.breed from";
sql += " dogs inner join dogbreeds on";
sql += " dogs.breed = breed.breed where dogs.ownerId in(" + values + ")";
if (filterType == "12")
{
sql += " and coat='curly'";
}
results = DatabaseWrapper.GetManyResults(sql);
break;
default:
sql = "select name, population from countries,people on where people.countryname = countries.name and people.id in(" + values + ")";
if (filterType == "f")
{
sql += " and countries.continent='South America'";
}
if (filterType == "642")
{
sql += " and countries.continent='Europe'";
}
results = DatabaseWrapper.GetManyResults(sql);
break;
}
}
return results;
}
}
}
Run the code
Some great advice from Michael Feathers goes something like this: "if you need to see what some code does, run it." In practice, this means write a test that exercises the code, and see how far it gets without failing. If it doesn't fail, that route through the code has no dependencies and will be easier to write tests for. If it does fail, it will highlight dependencies that need to be abstracted.
To run some code, the first job is to find a suitable entry point to the method. If the method to test is public or internal, that's the entry point. If not, is the method called from a public or internal method? If not, the method should be made internal to allow it to be called directly.
The method on the Data class that needs testing is the public GetData method. Here's the first test:
[TestFixture]
public class GetData
{
[Test]
public void WithEmptyArgs()
{
var target = new Data("");
target.GetData("", "", "", false);
}
}
When this runs, the GetData method fails on a call to the DatabaseWrapper class, showing that there's a dependency on that class that needs to be faked for testing.
public ArrayList GetData(string code, string gdr, string filterType, bool getAge)
{
ArrayList results = null;
var sql = "select id from people where type = " + _type + " and gender ='" + gdr + "'";
string values = DatabaseWrapper.GetSingleResult(sql);
//Code fails in call to GetSingleResult
Deal with dependencies
If the DatabaseWrapper class was an instance, the best way to deal with it would be to extract its interface and use that interface through the code, allowing a stub to be used from a test. However, in this example DatabaseWrapper is a static class, so needs to be dealt with in a different way.
One way would be to add an instance wrapper class around the static class (DatabaseWrapperWrapper..?). This would call the static method from within that class's instance methods, and allow an interface to be used in the GetData method.
Another way is to add a protected virtual method in the Data class that wraps the static method; this allows the test code to use a subclass of the Data class, and override the virtual method. I'll demonstrate that. Here's the new virtual method and its usage in the GetData method:
protected virtual string GetSingleResult(string sql)
{
return DatabaseWrapper.GetSingleResult(sql);
}
public ArrayList GetData(string code, string gdr, string filterType, bool getAge)
{
ArrayList results = null;
var sql = "select id from people where type = " + _type + " and gender ='" + gdr + "'";
//Now calls virtual method
string values = GetSingleResult(sql);
and here's the usage in the test project. There's a new class, FakeData, that extends Data. This has an override of the virtual GetSingleResult method, returning an empty string for now. Note that the FakeData class is the new target for the test.
[TestFixture]
public class GetData
{
[Test]
public void WithEmptyArgs()
{
var target = new FakeData("");
target.GetData("", "", "", false);
}
private class FakeData : Data
{
public FakeData(string type)
: base(type)
{ }
protected override string GetSingleResult(string sql)
{
return "";
}
}
}
The code under test now runs up to the call to DatabaseWrapper.GetManyResults, so the GetManyResults method needs a virtual wrapper the same as GetSingleResult did:
the calls to DatabaseWrapper.GetManyResults need to be changed to the local GetManyResults:
...
default:
sql = "select name, population from countries,people on where people.countryname = countries.name and people.id in(" + values + ")";
if (filterType == "f")
{
sql += " and countries.continent='South America'";
}
if (filterType == "642")
{
sql += " and countries.continent='Europe'";
}
// Now calls the virtual method
results = GetManyResults(sql);
break;
...
and the FakeData class in the tests needs to override the method:
private class FakeData : Data
{
public FakeData(string type)
: base(type)
{ }
protected override string GetSingleResult(string sql)
{
return "";
}
protected override ArrayList GetManyResults(string sql)
{
return new ArrayList();
}
}
Now there's a test that mocks a call to the database, and runs through the method from start to finish. But because of the many responsibilities of the code, what needs to be asserted - the SQL that is being executed on the database - is not exposed outside the GetData method.
Sensing variables
In order to see the value of the SQL being executed, the test class will use a "sensing variable". This is a variable that stores a runtime value so that it is available for a test to perform an assertion on. In this example, the sensing variable will be on the FakeData class, and will store the value of the SQL string passed to the GetManyResults method.
[TestFixture]
public class GetData
{
[Test]
public void WithEmptyArgs()
{
var target = new FakeData("");
target.GetData("", "", "", false);
// Use the sensing variable in the assertion
Assert.That(target.ExecutedSql, Is.EqualTo(""));
}
private class FakeData : Data
{
// The sensing variable
public string ExecutedSql { get; private set; }
public FakeData(string type)
: base(type)
{ }
protected override string GetSingleResult(string sql)
{
return "";
}
protected override ArrayList GetManyResults(string sql)
{
//Store the value in the sensing variable
ExecutedSql = sql;
return new ArrayList();
}
}
}
A well-placed breakpoint allows the sensing variable's value to be harvested, and used as the expected result for that test.
[Test]
public void WithEmptyArgs()
{
var target = new FakeData("");
target.GetData("", "", "", false);
const string expected = "select name, population "
+ "from countries,people on where people.countryname = "
+ "countries.name and people.id in()";
Assert.That(target.ExecutedSql, Is.EqualTo(expected));
}
Which gives the first green test!
Although this single test is not particularly useful, the journey to get to it has shown some techniques that are available when tackling legacy code. In future posts I'll write more tests and get to a point where it's safe to refactor the code. The I'll refactor the hell out of it.
In Summary
Run the code
Identify the start point
Make method visible (public/internal)
Write a test to exercise the code
Deal with dependencies
Introduce interface for instance class
Wrap a static class in an instance class
Create virtual method to hide static method calls
Sensing variables
Use to surface runtime values
If there are other techniques that you employ to refactor legacy code, I'd like to know what they are - they are all useful.
This has been blogged elsewhere, but I was *so* amazed to see this that I needed to share it. All credit goes to Tom (@photomoose) for doing this while I was watching.
If you have Windows Explorer open and need a command prompt in that directory:
Go to the address bar, remove the directory name and enter "cmd"
Press enter, and voilà, your command prompt, initialised to the current directory.
Shift-Right Click
Thanks to John (@imaji) for this tip.
If you hold Shift and right-click in Windows Explorer, you get an item added on the popup menu. The non-shift version looks like this:
