Jan 12, 07:52 AM
While this is not something I personally would want to do, we (for whatever reason...) are to use MSTest at work (I think it is due to the whole "Its Microsoft, so it’s supported" argument).
Now as no one else on the team does any kind of unit testing (serious), the only test projects we have are written by me, on the quiet before being told if I wanted to unit test then use MSTest. So onto the point of this article.
When you create a project for tests with nunit, you just create a Class Library, add a reference to nunit (and Rhino.Mocks of course), build it and run with your preferred method (I like TDD.Net, but that involves paying for at work...so no go there).
When you want to do tests with MSTest, you just create a Test Project and start writing tests. On closer inspection, it’s just a Class Library with a reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework. So converting one to the other should be easy, right?
Well not quite. While there is nothing in the GUI to suggest so, you need to modify the csproj/vbproj file to get it to work. This post on MSDN, had all the details, but in the interest of having things in more than one place (not very DRY I will admit, but there), here are the steps:
- Remove Reference to Nunit.Core & Nunit.Framework
- Add Reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework
- Find and Replace:
using NUnit.Framework; with using Microsoft.VisualStudio.TestTools.UnitTesting; (I actually use a project level import, so I skip this)
- [TestFixture] -> [TestClass]
- [Test] -> [TestMethod]
- [SetUp] -> [TestInitialize]
- [TearDown] -> [TestCleanup]
- [TestFixtureSetUp] -> [ClassInitialize]
- [TestFixtureTearDown] -> [ClassCleanup]
- Change your Asserts:
- Assert.Greater(x, y) -> Assert.IsTrue(x > y)
- Assert.AreEqual(x, Is.EqualTo(y).IgnoreCase) -> Assert.AreEqual(x, y, True)
- The 'hidden' part. In your project file, locate
<PropertyGroup> (not the one specifying debug|release settings), and add the following to it:
- 512
- *.csproj files add:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
- *.vbproj files add:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{F184B08F-C81C-45F6-A57F-5ABD9991F28F}</ProjectTypeGuids>
This was all I had to do to get our (my) tests running again under MSTest. Except they didn’t run, with the lovely error of:
The location of the file or directory 'D:\Projects\Dev\SDK\Rhino.Mocks.dll' is not trusted.
That’s odd, the file is on my hard disk, its not a network share, so what’s the problem? Right click on Rhino.Mocks.dll and:

Click the button, hit Apply, re-run the tests. All Working now :)
There are a few other points mentioned on the MSDN post too which you may run into:
If you have relied on NUnit TestFixtureSetup and TestFixtureTearDown methods to do non-static things, will have to move functions in the former to a constructor and the latter to a destructor. In MSTest, both of these methods must be declared as static.
If you are relying on AppDomain.CurrentDomain.BaseDirectory to get the root directory, your test will break. The fix is explained at http://www.ademiller.com/blogs/tech/2008/01/gotchas-mstest-appdomain-changes-in-vs-2008/. Basically, you need to set your BaseDirectory in your MSTest TestClass constructor like this:
string currDir = Environment.CurrentDirectory.Substring(0, Environment.CurrentDirectory.IndexOf("TestResults"));
AppDomain.CurrentDomain.SetData("APPBASE", currDir);
MSTest launches each test method in a separate STA thread instead of the MTA thread you may be expecting. This probably won’t give you any problems.
Hope that helps everyone who has to do this kind of conversion.
— Andy
Code, .net
Dec 16, 01:06 PM
Following on from yesterday's post about separation on concerns and where to put some undefined logic for a multi state checkbox, I did a fair amount of research.
I must say the Quince website is a good repository of UI Design Patterns, as is Welie. I couldn’t find anything like what I was after, which I guess means I shouldn’t be doing it this way?
After a while a brainwave struck me: "Gmail lets you select things, how does it do it?” One click on the Gmail icon and I'm presented with this:

Perfect. So I went back to my sponsor and showed them a mock-up with this style of selection. The reaction was: "Oh I like that". Excellent news, for me its easier code to write (I’m happy with a for loop setting a grid cell to true in the view) and if they want to add other selections its easy enough (though there is not much else they could select by...).
The moral of the story? If in doubt, copy Google.
— Andy
Code, Design, .net
Dec 15, 01:37 PM
When I am writing a winform in a MVP style, I often wonder how far to go with the separation. Say I have the following situation:
A Small form which should display a list of messages, and allow the user to select which ones they want processed. It processes each message in turn. If a message has more than one attachment, a dialog is shown to ask the user to select which attachment should be used for that message.
Now while this is fairly simple, my interface for the message dialog looks like this:
Public Interface IMessageSelector
Event Submit()
Event Cancel()
WriteOnly Property Messages() As IList(Of MessageData)
ReadOnly Property Selected() As IList(Of String)
ReadOnly Property AttachmentView() As IAttachmentScreen
Sub ShowScreen()
Sub CloseScreen()
Sub DisplayWarning(ByVal text As String)
End Interface
In the form I have (roughly) the following:
Public Class frmMessages
Implements IMessageSelector
'...'
Public WriteOnly Property Messages() As IList(Of MessageData) Implements IMessageSelector.Messages
Set(ByVal value As IList(Of MessageData))
For Each d As MessageData In value
Dim r As Grid.Row = grid.Rows.Add
r("id") = d.ID
r("subject") = d.Subject
r("from") = d.Sender
r("received") = d.SendDate
Next
flx.AutoSizeCols()
End Set
End Property
Public ReadOnly Property Selected() As IList(Of String) Implements IMessageSelector.Selected
Get
Dim result As New List(Of String)
For i As Integer = 1 To grid.Rows.Count - 1
If Convert.ToBoolean(grid(i, "selected")) Then
result.Add(grid(i, "id").ToString)
End If
Next
Return result
End Get
End Property
End Class
Now I think that this is ok. There is not logic as such in the population property, and the Selected property just determines which rows have had their checkboxes ticked.
However it has been requested that I add a 'Select All/None' checkbox to the form. Where do I add the code for this? As they want a checkbox to tick or detick its not as trivial as it could be. If it were separate buttons, I could just use a for loop in each setting the values to True or False. A checkbox however has some uncertainties:
- Checking the master checkbox should make all rows checked. Fine.
- DeChecking the master checkbox should make all rows unchecked. Also fine.
- Checking one row when none are checked should do what to the master checkbox?
- DeChecking one row when all are checked should do what to the master checkbox?
- 25%/50%/75% of rows are checked, what does the master checkbox look like?
- Some rows are checked. What happens when the checkbox is clicked?
So many questions for such a simple looking feature. With so many possibilities for it maybe it should go into the presenter/interface? At least it’s testable then. Maybe a separate controller for it as it’s not really anything to do with the purpose of the form?
If anyone knows of answers to this I would be very interested to hear them.
— Andy
Code, Design, .net
Oct 7, 10:58 AM
This morning I read this post by Alfred Thompson about whether we are Software Engineers or something else. I can’t help but agree with him, as I don’t feel we are engineers (yet), our discipline is a little fuzzy to be classified as engineering I think.
However I think we are not alone in this boat. Not all engineering disciplines are quite so well cut. My father is an Engineering Pattern Maker. Yet a large proportion of his work involves hand tools to create his forms. Maybe the designing of the Pattern is engineering, but the creation of it is defiantly crafting as so much practical skill is involved in the creation. If instead of him making it, the design was given to a nice brainless CNC to make, would that CNC be as skilled and thus a craftsman(machine?), or would it magically become engineering due to the lack of a CNC's skills?
The same goes for science in my mind. This might be due to Robert M. Pirsig's excellent book [Zen and the Art of Motorcycle Maintenance], where he goes to explain that science is about having a theory(s) then proving or disproving it, and continuing until all theories have been eliminated. At this point you have 'fact', or have missed some theories. His main point on this was 'where do theories come from? If you are sat there with no theories, and then you suddenly think of one, where did it come from? It certainly does not seem like a scientific method of theory discovery' (I don’t have the book to hand, so can’t find the exact quote. I will update later when I get home). So science is a bit 'fuzzy' too?
This also applies to art. If a sculpture is to be created, it needs to be structurally sound, else it just won’t work. So some engineering is involved there too. And possibly science of materials too.
I think my point is that we are just trying to label everything into distinct categories, which just isn’t going to work, unless your categories are so wide that they might as well not exist.
— Andy
Code
Oct 6, 12:13 PM
There seems to be a lot of negativity towards the #Region in .net at the moment, with many people hating them and calling all usages of them 'retarded'.
I can see their point, especially when you see the odd class with regions like this:
Class Foo
{
#Private Members
#Protected Members
#Friend Members
#Public Members
#Private Constructors
#Protected Constructors
#Friend Constructors
#Public Constructors
#Private Methods
#Protected Methods
#Friend Methods
#Public Methods
}
Clearly the person who wrote this was ill at the time (I hope...), and besides, where would Protected Friends go? Hmm?
I however find regions useful, especially when writing objects (see what I did there?). Now while an object might have might be DRY and only have a Single Responsibility, it might also have many properties. What I tend to do with regions is hide my getters and setters:
Class Bar
{
Member1
...
Member2
#Region Properties
//....
#End Region
Method1(){/* */}
...
Method1(){/* */}
}
This way I am hiding standard boiler plate code, and everything that actually matters is visible. If you don’t like hiding properties that have a lot of code in them, then your problem may be the fact that you have lots of code in the properties. Something like PostSharp could allow you to inject all your properties with the common code such as PropertyChanging(sender, e), PropertyChanged(sender, e).
If you need lots of specific code in a property, then it is surely under unit test? If it isn't, why not? And if it is, does it matter that you can’t see the property without clicking the little + sign?
One other slight point: with my method of #region usage, if you don’t like regions, you have one click to expand it (or if you don’t like clicking, Ctrl+M, Ctrl+M in VS will expand/collapse whatever is at the cursor position), so it really is not that difficult to cope with.
Like all technologies, use it when it makes sense. No Regions can be just as bad as many Regions.
— Andy
Code, Design, .net