Let the Tour Begin!
Sandi and I have decided to embark on a true dream for college basketball geeks (we are). We are going to attempt to visit all power conference/'BCS schools' (SEC, ACC, Big 10, etc.) schools for a home basketball game.
It will take us several years, but I think once we get organized we'll be able to start knocking them out. We started last Tuesday with a trip to our neighboring state's capitol city, Columbus, Ohio to watch the Buckeyes take on the Cyclones of Iowa State.
We were really wanting to see the guys from Indy play before either of them go pro (Mike Conley Jr. and Greg Oden). It was a great game and the Bucks came out victorious. Our seats were Awesome (note the capital A). Fifth row, practically on the court!
At half time the football team came out and presented the Big 10 championship trophy and Troy Smith presented his Heisman to the school. No matter how good their basketball team is, OSU will ALWAYS be a football school, and we could really feel how much everyone there supports that football program... it was a rush.
The next night we made the trip back westward to Bloomington, a town which I've heard called 'A drinking town with a basketball problem.' Sandi and I are IU basketball freaks, so we were totally stoked except for the fact I was sick.
This game turned out great as well. We got to see our favorites DJ White and Errek Suhr, and all the rest as well. The Hoosiers came out on top after a half-time deficit (shew, that sounded a little bit like Radio-Rob).
A great week of vacationing and a great kick-off of the tour. Pictures will be posted shortly of some of the happenings as well.
Mock Objects… Firing Events
UPDATE: I finally am posting the source here!
It has been long enough since I've made my last post, but with the recent posting from Eli's blog about TypeMock on Firing Events when mocking/testing, I thought I would throw out my solution to this problem for those of us using NMock2.
If you're not familiar with mock objects, there is some great content out there, just google it (you didn't think I was actually going to explain them here did you?!)
First off, I love NMock2. It does what I need and stays out of my way. The syntax is terse and flows like prose.
On with the content!
Part 1: Ready
It seems obvious to me, that if you're using mock objects, you're most likely going to run across a mock that needs to fire an event. It's almost like the NMock2 guys completely skipped over this use case (but I'm not knocking them, this is a great product). After digging around in reflection trying to figure how to do what I wanted and discussing it with a colleague of mine, I was turned on to the idea of using Custom Actions to catch the event add's and remove's [part 1] and store them off for invocation later (when the event is actually fired) [part 2].
Part 2: Aim - Catching the Event Add's and Remove's
The great thing about a custom action (type IAction), is that you get all sorts of information about the thing that actually got invoked. In our case, the adder or remover of an event. Similar to properties, the add/remove 'accessors' are compiled into methods just like the get/set accessors. The naming of these generated methods is also similar. For a property's get/set, the names look like:
get_<PropertyNameHere>
set_<PropertyNameHere>
Likewise, for the add/remove 'accessors' for an event get names:
add_<EventNameHere>
remove_<EventNameHere>
Armed with this information, we can tell if the method being called is an event adder/remover. The syntax for catching an event add is as such:
Expect.Once.On(mockButton).EventAdd("Click",
Is.Anything).Will(Catch.EventAdd);
Similarly, event removal looks like:
Expect.Once.On(mockButton).EventRemove("Click",
Is.Anything).Will(Catch.EventRemove);
Part 3: Fire!
Great! We know when events are added! But wait, it still seems like we haven't gotten anywhere (but really we have). The Catch.EventAdd takes the method that got called (add_Click), and grabs the single argument from the method call which happens to be an EventHandler type delegate (in this case), and stores it off to be invoked later when the event gets fired.
Event.Fire("Click").On(mockButton).With(this,
EventArgs.Empty);
This call invokes all of the methods that were caught when being added to the mockButton's Click event with the given parameter values.
Often times it is useful for an event to be fired when some other mocked method gets called. For this case, a custom action should suit just fine; simply pass it into the Will portion of your expectation/stub setup for that particular method. That means, as soon as the mocked method gets called, the event will fire just as if the above line of code was executed.
Expect.Once.On(mockButton).Method("PerformClick").
Will(Event.Fire("Click", mockButton, this,
EventArgs.Empty));
Here is a complete example that pulls it all together:
interface IButton
{
event EventHandler Click;
void PerformClick();
}
class ButtonTester
{
private bool clicked;
[SetUp]
public void Setup()
{
clicked = false;
}
[Test]
public void TestButtonFire()
{
Mockery mocker = new Mockery();
IButton mockButton = mocker.NewMock(typeof(IButton)) as IButton;
Expect.Once.On(mockButton).EventAdd("Click", Is.Anything).Will(Catch.EventAdd);
// Normally exercise domain code here,
// but we'll keep it simple and inline.
mockButton.Click += delegate(object sender, EventArgs args) { clicked = true; };
Event.Fire("Click").On(mockButton).With(this, EventArgs.Empty);
Assert.IsTrue(clicked);
mocker.VerifyAllExpectationsHaveBeenMet();
}
[Test]
public void TestPerformClick()
{
Mockery mocker = new Mockery();
IButton mockButton = mocker.NewMock(typeof(IButton)) as IButton;
Expect.Once.On(mockButton).EventAdd("Click", Is.Anything).Will(Catch.EventAdd);
Expect.Once.On(mockButton).Method("PerformClick").Will(Event.Fire("Click", mockButton, this, EventArgs.Empty));
// Normally exercise domain code here,
// but we'll keep it simple and inline.
mockButton.Click += delegate(object sender, EventArgs args) { clicked = true; };
mockButton.PerformClick();
Assert.IsTrue(clicked);
mocker.VerifyAllExpectationsHaveBeenMet();
}
}
Thats it. This stuff is currently unreleased, but feel free to send requests, I'll gladly send a copy.
Ch-Ch-Changes
Today marks the (somewhat) official day of my transition (within the company) to a new team/job/product. I have been working on FACS Workstation, which is a .NET front-end to the product that has sustained the company throughout the past ~20 years, FACS. This is/was my first job out of college and are the only guys I've ever worked with in the 2 1/2 years I've been out. They are a great bunch of guys, and I hate to leave them, but it seems it was inevitable.
I will be starting on our company's new flagship product named Artiva. I don't know my team (as of yet), I don't know my area of the product (as of yet), and I don't know what kind of development environment I'll even be working in... but I'm doubting it will be .NET or even anything OO.
I love my job now, and am very passionate about FACS Workstation and want to see it succeed so I am reluctant to change positions. However, I think this may be a great opportunity to leave the comfort zone and broaden my skill set both as an employee and as an individual. Change is good right?
I am certain I will be given an immense amount of stuff to learn and will probably be doing some research as well, so there may be several good posts coming soon on techie stuff (just so I can keep track of it all, not that you all care)... that is if I'm not too lazy to write it down.
Tags
Books I’m Reading
Social
-->
View Jon Fuller's profile
