NMock expectations for functions accepting “ref” and “out” arguments
There appears to be inadequate documentation on setting up expectations in NMock for methods that accept arguments by reference using “out” and “ref” keywords. Here is a quick note to give an example demonstrating how it can be done.
Consider the following interface:
public interface IFoo
{
void Bar(out int a, ref int b);
}
“Bar” method takes one “out” parameter and another “ref” parameter.
To start mocking “IFoo” you would obviously first create a new mock object implementing interface “IFoo”.
IFoo aFoo = mocks.NewMock< IFoo >();
We store it in a variable named “aFoo”.
Here’s how you would set up an expectation to ask NMock to expect a call to method “Bar” on “aFoo” object with an “out” parameter and a “ref” parameter with 2 as its value.
Expect.Once.On(aFoo)
.Method("Bar").With(Is.Out, 2)
.Will(new SetNamedParameterAction("a", 10),
new SetNamedParameterAction("b", 20));
The actions specified in the “Will” part cause the “out” and “ref” parameters to be set to values 10 and 20 respectively after “Bar” is called on “aFoo”.
int a, b = 2; aFoo.Bar(out a, ref b); // At this point "a" will be set to 10 and "b" will be set to 20 because // of the expectation specified above.
Hope this helps.
Automating windows forms UI testing
If you have been blessed with a windows-forms application that has business-logic invading the user-interface, I have something that’ll help you. The most practical approach in this situation is to rearchitect the business layer and switch the UI over in a piecemeal fashion. While you’re doing this, automated testing of the user-interface will make your job a lot faster compared to manual testing.
For the purpose of this article let us consider a simple Windows Forms application (download link below). The application allows the user to provide two inputs and then either add them or subtract them. Simple, right?
The application
Here’s the code for the event-handlers of interest to us:
private void MainForm_Load(object sender, EventArgs e)
{
this.lblAnswer.Text = "0";
}
private void btnAdd_Click(object sender, EventArgs e)
{
this.lblAnswer.Text = Convert.ToString(this.numericUpDown1.Value + this.numericUpDown2.Value);
}
private void btnSubtract_Click(object sender, EventArgs e)
{
this.lblAnswer.Text = Convert.ToString(this.numericUpDown1.Value - this.numericUpDown2.Value);
}
The handler for the load event of the form just sets the answer label to display “0”. The handler for the click event of each of the buttons retrieves the selected values from the numeric drop-downs, applies the appropriate operation, and writes the result into the label.
The tests
In order to write tests for this application, you can start by right-clicking on the class of the form (in this case MainForm), and selecting “Create Unit Tests…”. Hit “OK” on the dialog that pops up to create unit-tests in a separate project. Another dialog will pop up asking for the name of the test project. Just hit “Create”.
This will cause Visual Studio to do some heavy lifting for us and generate accessors to allow us to call methods and properties defined on MainForm, from our tests. We don’t have to write code for accessors using the Reflection API ourselves – so this is extremely cool. Doing it on our own is quite painful (proof).
Delete all the tests marked with the TestMethod attribute in the generated class because we’re going to write our own.
The first one is pretty simple. We expect the answer label to display a “0” when the form is initially loaded – so let’s test that.
/// <summary>
///A test for MainForm_Load
///</summary>
[TestMethod()]
[DeploymentItem("AppUnderTest1.exe")]
public void MainForm_LoadTest()
{
MainForm_Accessor target = new MainForm_Accessor();
target.MainForm_Load(null, null);
Assert.AreEqual("0", target.lblAnswer.Text, "Initial answer is zero");
}
Notice that we can call MainForm_Load directly (no ConstructorInfo, MethodInfo – reflection stuff required).
Once that’s done we can just check the text displayed in the answer label and make sure it is “0”.
We can take the same approach to call the click event handlers of the buttons and check the results for addition/subtraction.
Since there are various cases to test, I have a separate function GetTestTable that returns a two dimensional array where each row contains the two test-inputs, result of subtraction, and result of addition – in that order.
public int[,] GetTestTable()
{
// Format of each row:
// A, B, (A-B), (A+B)
int[,] table =
{
{0, 0, 0, 0},
{10, 0, 10, 10},
{0, 10, -10, 10},
{-10, 0, -10, -10},
{0, -10, +10, -10},
{10, 10, 0, 20},
{-10, -10, 0, -20},
{-10, 10, -20, 0},
{10, -10, 20, 0}
};
return table;
}
Following is the function that actually does the testing. We basically process each row returned by GetTestTable one by one. First we set the two inputs on the numeric drop-downs. Next we call the click event-handlers of both buttons verifying what is in the answer label against what we expect. Again notice that we can directly invoke the event handlers and even access properties of the answer label (lblAnswer).
/// <summary>
///A test for btnSubtract_Click
///</summary>
[TestMethod()]
[DeploymentItem("AppUnderTest1.exe")]
public void AddSubtractTest()
{
MainForm_Accessor target = new MainForm_Accessor();
int[,] table = this.GetTestTable();
for (int i = 0; i < table.GetUpperBound(0); i++)
{
int a = table[i, 0],
b = table[i, 1],
subtract = table[i, 2],
add = table[i, 3];
target.numericUpDown1.Value = a;
target.numericUpDown2.Value = b;
target.btnSubtract_Click(null, null);
int result = Convert.ToInt32(target.lblAnswer.Text);
Assert.AreEqual(subtract, result, String.Format("Subtract {0} and {1}", a, b));
target.btnAdd_Click(null, null);
result = Convert.ToInt32(target.lblAnswer.Text);
Assert.AreEqual(add, result, String.Format("Add {0} and {1}", a, b));
}
}
To run these tests, select Test->Run->All Tests in Solution from the main-menu in Visual Studio. The “Test Results” window in Visual Studio should show that all tests passed.
Summary
There’re multiple ways to go about automating UI testing. You could use an automated testing tool like Mercury Quick Test. However if you want to take things into your own hands and take advantage of greater control, you could write your tests using NUnit or MS-Test and make PInvoke calls to send messages to various controls in the UI of your application under test. You could use the SendKey API in Windows.Forms too.
However if you want to take advantage of knowledge of the internals of the application under test, we have to use Reflection to set properties of the controls, invoke event handlers, call other methods and then test whether this resulted in the changes that we expected. This makes the job extremely painful. I hope this article shows how much easier it is if we leverage Visual Studio Team System to generate accessors for us.
I don’t see why the technique described above cannot be used to test WPF and Silverlight applications as well.
Download
Click here to download the code accompanying this article.
Automatic properties with custom logic – part 2
Let’s say we have a class called ShoppingCartItem. We’re going to concern ourselves with two properties here namely TaxID and Taxable. The business logic dictates that an item is definitely non-taxable if it has a tax-id of zero, otherwise it may or may not be taxable which is decided by some code situated outside the ShoppingCartItem class.
How would you write your ShoppingCartItem class?
Now – we cannot really take advantage of automatic properties over here.
public class ShoppingCartItem
{
public int TaxID { get; set; }
public bool Taxable { get; set; }
}
We really want the ShoppingCartItem to unset the Taxable flag when TaxID is zero. The setter for TaxID property seems to be the most obvious place to do that. But since we’re relying on the C# compiler to generate the getter/setter code we don’t really have control over that.
Of course, we have to fall back to the old way of doing it.
public class ShoppingCartItem
{
private int mTaxID;
public int TaxID
{
get
{
return this.mTaxID;
}
set
{
this.mTaxID = value;
if (this.mTaxID == 0)
this.Taxable = false;
}
}
public bool Taxable { get; set; }
}
That solves the problem we initially set out to solve but isn’t future proof. That’s because there’s nothing stopping a future programmer from adding new code in ShoppingCartItem class that directly saves values to mTaxID field instead of using the property setter. This could lead to Taxable being inconsistent with the value of TaxID. It would be better if we could somehow prevent direct setting of the backing field corresponding to the TaxID property even within the class.
Well, here’s an idea that leverages the lambda expression support in C# 3.0 to give us something that’s concise to write.
public class ShoppingCartItem
{
public PropertyValue<int> TaxID;
public PropertyValue<bool> Taxable;
public ShoppingCartItem()
{
this.TaxID = new PropertyValue<int>()
{
OnSet = value =>
{
if (value == 0)
this.Taxable.Value = false;
}
};
this.Taxable = new PropertyValue<bool>();
}
}
PropertyValue is the new class that I wrote. The idea is that you provide the code that should be executed when the TaxID is set, when initializing TaxID.
Here’s the code for the new class.
public class PropertyValue < T > : System.ComponentModel.INotifyPropertyChanged
{
#region Private fields
private Action mOnGet;
private Action mOnSet;
private T mValue;
#endregion
#region Constructors
public PropertyValue()
{
this.mValue = default(T);
}
public PropertyValue(T initialValue)
{
this.mValue = initialValue;
}
public PropertyValue(T initialValue, Action onGet, Action onSet)
{
this.mValue = initialValue;
this.mOnGet = onGet;
this.mOnSet = onSet;
}
#endregion
#region Properties
public Action OnGet
{
private get
{
return this.mOnGet;
}
set
{
if (this.mOnGet == null)
{
this.mOnGet = value;
}
else
{
throw new InvalidOperationException("Getter can only be assigned once.");
}
}
}
public Action OnSet
{
private get
{
return this.mOnSet;
}
set
{
if (this.mOnSet == null)
{
this.mOnSet = value;
}
else
{
throw new InvalidOperationException("Setter can only be assigned once.");
}
}
}
public T Value
{
get
{
if (this.mOnGet != null)
{
this.mOnGet(this.mValue);
}
return this.mValue;
}
set
{
this.mValue = value;
if (this.mOnSet != null)
{
this.mOnSet(this.mValue);
}
if (this.PropertyChanged != null)
{
this.PropertyChanged(this, new System.ComponentModel.PropertyChangedEventArgs("Value"));
}
}
}
#endregion
#region INotifyPropertyChanged Members
public event System.ComponentModel.PropertyChangedEventHandler PropertyChanged;
#endregion
#region Overridden base class methods
public override string ToString()
{
if (this.mValue != null)
{
return this.mValue.ToString();
}
else
{
return base.ToString();
}
}
#endregion
}
While it does appear to solve the issue, I’m not quite satisfied. So let me end this by pointing out the things I don’t like in the implementation and ask for ideas:
-
It is wordier compared to the automatic property support in C# and requires you to know about lambda expressions. Here’s how I think it should have been:
public class ShoppingCartItem { public int TaxID { get; set { if (value == 0) this.Taxable = false; } } public bool Taxable { get; set; } }This doesn’t work in C# 3.0 and generates a compiler error “ShoppingCartItem.TaxID.get’ must declare a body because it is not marked abstract, extern, or partial”.
-
Ideally, I should have been able to write the following which seems more succinct.
public class ShoppingCartItem { public PropertyValue<bool> Taxable = new PropertyValue</bool><bool>(); public PropertyValue<int> TaxID = new PropertyValue</int><int>() { OnSet = value => { if (value == 0) Taxable = false; } }; }But I cannot, because it generates a compiler error “A field initializer cannot reference the non-static field, method, or property”. This requires me to do the same thing inside the constructor which introduces an extra step.
What do you think?
Automatic properties with custom logic
There should be a compiler supported way in C# to declare a property with custom getter/setter logic without having to explicitly declare a backing field. In the absence of such a feature, if you want to have custom getter/setter logic you have to ditch automatic properties, declare a backing field explicitly and then there’s nothing stopping a future programmer from assigning directly to the backing field and the custom getter/setter logic not getting executed probably leading to bugs.
Update:Check out part 2 where I take an example to bring the problem into perspective and propose a solution…
“Add Service Reference” option not appearing in Visual Studio 2008
Had to do a bit of head-scratching on this one. New projects created in Visual Studio 2008 did show the “Add Service Reference” when right-clicking on a project in Solution Explorer while some existing ones didn’t.
Using “Add Web Reference” instead of “Add Service Reference” has its own set of issues in that WCF services are meant to be used with DataContractSerializer. “Add Web Reference” utilizes XmlSerializer which might lead to some surprises when consuming WCF web-services. The way the two serializers handle WSDL is different. This article explains why you might find that property values of your complex types in web-services do not reach all the way to the web-service from the client.
Somebody logged a Microsoft Connect ticket on this but didn’t receive an answer because the issue couldn’t be reproduced.
Anyway, if you’re facing this issue – make sure that the target framework for your project is .NET 3.0 or later (you can do this in the Application tab of your project’s properties). You need to do this extra step if you upgrade your project to Visual Studio 2008 from older versions otherwise “Add Service Reference” wouldn’t appear. You can target .NET 2.0 from Visual Studio 2008 projects and that’s the default behavior during upgrade.
Update: This didn’t fix the issue for you? Check the comments for more alternatives.
A simple RTF report generator
I was describing how a simple yet extensible report-generator could be implemented quickly to somebody. I’m posting it here as some of you might find it useful (and I can refer to this link in future conversations 
).
The concept:
…is really simple. The idea is to look for a placeholder like @Fruit and replace it with “Apple”. However to make the whole thing extensible, reflection is used. When calling the report generator, you need to specify a reportInput object (can be of any type), in addition to the file-paths of input and output reports. The report-generator uses reflection to determine the properties available on the reportInput object. For each property, it derives a tag name and substitutes the derived tag name with the actual property value in the input file. The text read from the input file after making replacements is finally written to the output file. For further extensibility, the tag format is not hard-coded and can be specified as an argument.
Before (an RTF file with placeholders):
After (an RTF file with placeholders replaced with values):
The code:
public static class SimpleReportGenerator
{
public static void Generate(string inputFilePath, string outputFilePath, object reportInput, string tagFormat)
{
if (string.IsNullOrEmpty(inputFilePath))
throw new ArgumentException("inputFilePath");
if (string.IsNullOrEmpty(outputFilePath))
throw new ArgumentException("outputFilePath");
if (reportInput == null)
throw new ArgumentNullException("reportInput");
if (string.IsNullOrEmpty(tagFormat))
throw new ArgumentException("tagFormat");
string inputFileText = File.ReadAllText(inputFilePath);
StringBuilder reportOutput = new StringBuilder(inputFileText);
Type reportInputType = reportInput.GetType();
PropertyInfo[] properties = reportInputType.GetProperties();
foreach (PropertyInfo property in properties)
{
string propertyTag = String.Format(tagFormat, property.Name);
object propertyValueObj = property.GetValue(reportInput, null);
string propertyValue = (propertyValueObj != null) ? propertyValueObj.ToString() : String.Empty;
reportOutput.Replace(propertyTag, propertyValue);
}
File.WriteAllText(outputFilePath, reportOutput.ToString());
}
}
An example:
Defining ReportInput
public class ReportInput
{
public string ReportTitle { get; set; }
public string ReportHeading { get; set; }
public string ReportBody { get; set; }
public string ReportAuthor { get; set; }
public DateTime ReportDate { get; set; }
}
Creating a ReportInput for testing
public ReportInput GetTest()
{
ReportInput input = new ReportInput() { ReportAuthor = "John Doe", ReportBody = "A quick brown fox jumped over a lazy dog", ReportDate = DateTime.Now, ReportHeading = "The new report", ReportTitle = "Here we go" };
return input;
}
Generating a report
string input = "testreport.rtf";
string output = "testreport_out.rtf";
ReportInput reportInput = GetTest();
// "@{0}" indicates that a property named "Foo" corresponds to "@Foo" tag in the input file.
SimpleReportGenerator.Generate(input, output, reportInput, "@{0}");
ArrayList item comparison
What’ll be the output of the following piece of code (asked here)?
ArrayList a = new ArrayList(); ArrayList b = new ArrayList(); a.Add(1); b.Add(1); a.Add(2); b.Add(2.0); Console.WriteLine(a[0] == b[0]); Console.WriteLine(a[1] == b[1]);
One might expect…
True
True
But what you’d actually get is…
False
False
…because of boxing.
a.Add(1) boxes the integer 1 into an object and stores it in a, while b.Add(1) boxes the integer 1 into a separate object and stores it in b. Since a[0] and b[0] are going to be different objects, the check is going to fail. Same logic applies when comparing a[1] and b[1].
However, it gets interesting. If you tried to do a similar thing in VB.NET, the output would be different.
So with a code like this…
Dim a as new ArrayList() Dim b as new ArrayList() a.Add(1) b.Add(1) a.Add(2) b.Add(2.0) Console.WriteLine(a(0) = b(0)) Console.WriteLine(a(1) = b(1))
The output is going to be…
True
True
Surprised Well, VB.NET compiler translates the equality check (”=”) to a call to a helper function part of VB.NET runtime which would cast the left and right hand sides appropriately before comparison. In the first case, it would compare the two objects as integers, while in the second case it would compare the two objects as doubles after converting the integer on left hand side to a double.
That’s why we have generics - no surprises like these…
What you should do…
I am fortunate enough to work with a couple of great individuals. Recently I was able to hypnotize persuade them into discussing things which should and shouldn’t be done in a software project
I am absolutely sure that the discussion will help me in the future (and them). However I thought the merged list is generic enough to help anyone, and hence this post.
In the beginning…
- Before you start on a project, follow up with your managers and ensure that a detailed feasibility analysis has been done. This should include business planning, market analysis, and of course technology investigation to identify major road-blocks that are likely to be encountered in the future. For the technical analysis, you must involve the person who is going to actually write most of the code later on – because he’s the only one who’s most likely to consider all the possible issues.
- Involve engineers during requirement gathering phase. If possible, ask each of them to take a good look at a system of other competitors and report back with their findings. This will help the Product Manager in that there’s a better guarantee of the surface area of features being covered. The other bigger benefit is that the engineers would have a much clearer idea of the sort of product they’re supposed to build without having to read hundreds of pages in the requirements documents. This will also make them, I believe, more receptive to changes made in the requirements later on as they’ll have a better picture of the landscape. Being receptive to changes is very important.
- Identify major fears and unknowns that can negatively affect the outcome of a project. Make a proactive effort to address them at the start of the project.
- Make responsibilities of all individuals involved in the project clear for accountability. Assign roles to them appropriately.
- There should be a designated Project Manager whose role should be to maintain timelines, and escalate issues up to and from senior management. Asking a person in another role to also perform as a PM might not be effective always.
Day to day…
- Obtain sign-off for technical decisions and have a general plan for proceeding if a sign-off is not made within a specific amount of time.
- Daily standup meetings help a lot in keeping every one up to date on status and outstanding issues. There’s a lot to be learned from body language which might otherwise be lost in other forms of communication. However it is important to keep the meetings short – 10 to 15 minutes. There’s lots of literature about how the meetings should and shouldn’t be done. I’ll just say that you need to try out different things and pick the one which works best with the personalities of the individuals in the team.
In the meetings…
- Long weekly meetings drain the energy out of people and consequently the project. While I have my doubts on whether people pay attention after 45 minutes on average, I have even stronger doubts on the effectiveness of the meetings that go on for more than 2 hours. There might be exceptions of course, and I’d be interested in knowing what they did differently.
- After the weekly meeting, ensure that the meeting minutes are sent out describing each item discussed in the agenda along with the decisions made, open issues, and action items (assigning a person responsible).
- Be on time in meetings. Try to attend the meetings physically instead of over phone.
- Try to avoid taking calls on your cell phones during meetings – especially when you are actively involved in a discussion.
- Making decisions based on consensus is not always effective. Making decisions without considering inputs from others is equally bad.
When conducting code / design / UI reviews…
- If the process is to do design / code reviews in the meetings, to make the review more effective, try to restrict the number of attendees to the minimum absolutely necessary. Assigning reviewers to subsystems, if possible, might help in this regard.
- When performing a code review ensure that you enforce the positive aspects of the code, while identifying the aspects that need improvement. Too many details are bad; only give as many specifics as you think are needed to send the developer whose code is being reviewed forward in the right direction. When performing a review, pay attention and make an honest effort to understand the problem being posed to you.
When your code / design / UI is being reviewed by someone…
- When asking someone for a code / design review, make a dedicated effort to get their feedback. This might require you to spend an hour preparing a sample application to demonstrate the problem, but the time spent in it would be worth the effort. Be open to feedback. Negative feedback is still better than no feedback at all.
In general…
- Do not shoot down ideas point blank. This erodes the enthusiasm of the contributors which is very difficult to get back. Make sure you identify the positive aspects of every idea.
- Do not be afraid to hire temporary contractors and subject matter experts if required. That’s why a feasibility analysis is important.
- When involving new people in a project, ensure that they have received adequate training on other internal products and frameworks as required.
- If you’re required to use a common piece of code, ensure that it has an adequate test-bed. Secondly, push for dedicating engineering resources for their maintenance, depending of course on the size of the common code. If there aren’t any developers accountable for the upkeep of the common piece of code, you’re likely to lose the confidence of the developers who’re supposed to use it.
But most importantly…
- Work to a level where you can be proud of your contributions tomorrow. In the end, that’s all that matters.
Two (useless but potentially) interesting tid-bits
Try-Catch-Finally
A try-catch-finally is converted into IL by the C# compiler as a try-catch inside the try block of another try-finally. This allows for finally block to execute even when exceptions are raised in the catch block. Use ildasm and check it out yourself!
throw football;
Though you cannot throw an arbitrary managed object as “throw myObj” (you’ll get a compilation error), you can modify the generated IL to do so. However your catch block will actually receive a RuntimeWrappedException in these scenarios. Why is this allowed? Well, unlike C#, it is legal to throw arbitrary objects in managed C++ and in those cases a RuntimeWrappedException is thrown too.
C# compiler optimizations and empty “try” block
There is some misinformation you’re likely to stumble upon via Google when searching for “C# compiler /optimize+”. Interestingly, the following snippet can be seen on various forums.
The following is a response from a developer on the C# compiler team: We get rid of unused locals (i.e., locals that are never read, even if assigned). We get rid of unreachable code. We get rid of try-catch with an empty try. We get rid of try-finally with an empty try. We get rid of try-finally with an empty finally. We optimize branches over branches: gotoif A, lab1 goto lab2: lab1: turns into: gotoif !A, lab2 lab1: We optimize branches to ret, branches to next instruction, and branches to branches.
The part in bold is incorrect.
Before I dive into a simple app that I wrote to prove that the information is incorrect, there’s a simple logical reasoning to refute the claim. Basically, a function that has had a try/finally block completely removed because of an empty try or finally will behave completely differently than one who hasn’t. Optimizing something doesn’t mean you stop doing important things to save some time
“We get rid of try-finally with an empty try”. Do they really?
For those who still aren’t convinced with the explanation above, I wrote a simple C# class and saved it in a file Test.cs. I compiled the code once from the command line without optimizations (“csc test.cs”) and once with optimizations (“csc /optimize+ test.cs”).
Here’s what Foo looked like in C#:
private void Foo()
{
int x;
try
{
}
finally
{
DoSomething();
DoSomethingElse();
}
}
Nothing much there… Just an unused variable “x”, an empty try, and some code in the finally block.
Here’s the IL without optimizations:
.method private hidebysig static void Foo() cil managed
{
// Code size 22 (0x16)
.maxstack 0
.locals init (int32 V_0) // Here's our unused variable.
IL_0000: nop
.try
{
IL_0001: nop
IL_0002: nop
IL_0003: leave.s IL_0014
} // end .try
finally
{
IL_0005: nop
IL_0006: call void Test::DoSomething()
IL_000b: nop
IL_000c: call void Test::DoSomethingElse()
IL_0011: nop
IL_0012: nop
IL_0013: endfinally
} // end handler
IL_0014: nop
IL_0015: ret
} // end of method Test::Foo
Here’s the IL with optimizations:
.method private hidebysig static void Foo() cil managed
{
// Code size 14 (0xe)
.maxstack 0
.try
{
IL_0000: leave.s IL_000d
} // end .try
finally
{
IL_0002: call void Test::DoSomething()
IL_0007: call void Test::DoSomethingElse()
IL_000c: endfinally
} // end handler
IL_000d: ret
} // end of method Test::Foo
As you can see:
- The compiler got rid of the unused variable when optimizations were enabled
- Notice that the following declaration doesn’t appear in the second IL listing while it does in the first one:
.locals init (int32 V_0)
- Try / Finally is still there
If you’re still questioning why you would have a try/finally with an empty “try” in the first place, you might find an earlier article of mine interesting.
Hope this helps someone in an interview or something
