Tag: reflection

Farewell to the Last of My 40s

Posted on by Scott

Today is my 50th birthday, and looking back on my 40s from this vantage point, they were *a lot*.

I became a dad (to twins). They’re now in 3rd grade. In their 8 years, we’ve taken them to Disneyworld and to Atlanta to visit family and friends. COVID resulted in the twins spending their kindergarten year on Zoom. Our son (who has special needs requiring speech and occupational therapy) handled the Zoom year surprisingly well. Our daughter had a very rough time with the Zoom year. She desperately needed to be around children her own age.

On the work front, I went from being gifted President’s Club seats to Nationals games and box seats to the infamous “You Like That!” game at FedEx Field by my employer, to laid off from that same company and out of work for four months (the longest I’ve ever been out of work in my entire career). Over 6 years later, I still work for the same company that hired me out of unemployment, have been promoted twice, and helped a handful of my direct reports get promoted as well (the most successful of them went to Amazon, and is now a senior manager at Microsoft).

My 40s included a good amount of domestic and foreign travel (though the pandemic stole a few years of it). We kicked off my 40s with a trip to Europe that included Barcelona, Nice, Monaco, Dolceacqua (for the bridge there Monet painted), and London. Another trip to Europe included Amsterdam and Paris. Domestic travel has taken my wife and I to Los Angeles, Las Vegas, Scottsdale, New York, and Minneapolis. While the pandemic isn’t really over, I started taking an annual solo trip for brief break from parenting and other family responsibilities. Philadelphia and Boston were the destinations the past couple of years. And while a change in my work portfolio toward the end of last year has added a bit of work travel to my schedule, a trip entirely for me will get onto my itinerary for 2024 somehow.

Reflection and Unit Testing

Posted on by Scott

This post is prompted by a couple of things: (1) a limitation in the Moq mocking framework, (2) a look back at a unit test I wrote nearly 3 years ago when I first arrived at my current company. While you can use Moq to create an instance of a concrete class, you can’t set expectations on class members that aren’t virtual. In the case of one of our domain entities, this made it impossible to implement automated tests one of our business rules–at least not without creating real versions of multiple dependencies (and thereby creating an integration test). Or so I (incorrectly) thought.

Our solution architect sent me an unit test example that used reflection to set the non-virtual properties in question so they could be used for testing. While the approach is a bit clunky when compared to the capabilities provided by Moq, it works. Here’s some pseudo-code of an XUnit test that follows his model by using reflection to set a non-virtual property:

[Fact]
public override void RuleIsTriggered()
{
  var sde = new SomeDomainEntity(ClientId, null );
  SetWorkflowStatus(sde, SomeDomainEntityStatus.PendingFirstReview);

  var context = GetBusinessRuleContext(sde);
  Assert.True(RuleUnderTest.When(context.Object));
}

private void SetWorkflowStatus(SomeDomainEntity someDomainEntity, WorkflowStatus workflowStatus)
{
  var workflowStatusProperty = typeof(SomeDomainEntity).GetProperty("WorkflowStatus");
  workflowStatusProperty.SetValue(someDomainEntity, workflowStatus, null);
}

With the code above, if the business rule returned by RuleUnderTest looks at WorkflowStatus to determine whether or not the instance of SomeDomainEntity is valid, the value set via reflection will be what is returned. As an aside, the “context” returned from GetBusinessRuleContext is a mock configured to return sde if the business rule looks for it as part of its execution.

After seeing the previous unit test example (and a failing unit test on another branch of code), I was reminded of a unit test I wrote back in 2012 when I was getting up to speed with a new system. Based on the information I was given at the time, our value objects all needed to implement the IEquatable interface. Since we identified value objects with IValueObject (which was just a marker interface), using reflection and a bit of LINQ resulted in a test that would fail if any types implementing IValueObject did not also implement IEquatable. The test class is available here. If you need similar functionality for your own purposes, changing the types reflected on is quite a simple matter.