Mock Controller's User and Url Properties in ASP.NET Core MVC

Vigil Journey

I have come to the point where I am building out the initial proof-of-concept for the WebAPI portion of this project. This gives me a place to continue testing out features, and see if how I envisioned things would work can actually work. One of the first parts of unit testing the controller was to mock any of the properties that I need to use that the web server would ordinarily wire up. In a Controller that primarily entails the ControllerContext, which would also wire the Controller.User, Controller.Url, and Controller.HttpContext properties. So how do I do that?

Revisiting Creating and Updating Entities

Vigil Journey

Just when I thought I was in a good place to carry forward with retrieving a persisted entity and then modifying its values, I started looking intently into the CQRS Journey on MSDN. While reading through their narative, I thought I was really getting to understand how the code was structured. However, once I dug into the source code - well, I was naively mistaken. The notion of having a Factory was entirely flawed, as that role of validating and placing Commands on the Event Bus was better suited in the user interface layer (be it a Web Controller, a console library, or some other set of code). I supposed that the Factory could call under “some other set of code”; however, for the purposes of demonstrating the bare minimum needed to declare an action completed, the Factory was adding one too many steps. I realized that the unit test need not create a Factory to then pass a Command to the Bus. Instead, the Unit Test should assume the command was already on the bus.

User Can Update a Patron

Vigil Journey

A simple update of an object is as complex as adding a new instance of the object, which means it is both straight forward and laden with all kinds of caveats and unlying processes. As with creating a new Patron, it is trivial for me to put together a contrived example of code that will technically satisfy the requirements for “User Can Update a Patron”. A unit Test will create a new Command that will be validated by the Factory and then passed to the MessageQueue for persistance by some other process.

2016 Chicago Marathon Wrap-up

Exactly One Hobby

For the fourth year in a row, on Columbus Day weekend, I have completed the Bank of America Chicago Marathon. Previous years have culminated in mixed results, both by the clock and in my own experience. 2013’s marathon was a disaster in both time and how I felt during the race, but provided me with invaluable experience and a drive to do better. By the time the 2014 Chicago Marathon came around, I had taken up speed training with Coach Leach, focussed a little more on my running form, and put together a strong showing at the 2014 F3 Half Marathon. However, during last year’s race, I had set unrealistic expectations, especially while trying to run with a sore back. 2015 was not a good year for me, overall - but I was determined to turn things around for 2016.

A Word On Validation

Vigil Journey

For a while, I have been battling with where validation should occur, and who is responsible for ensuring that the information in a command is good data. For the first layer of data validation, I am turning to the Command to validate itself — the mere application of data types is a rudimentary form of data validation, so including addition simple validation extends that basic logic.

User Cannot* Create Patron That Fails Validation**

Vigil Journey

Creating a patron (by which I mean, issuing a command such that some process somewhere will instantiate an actual Patron entity, and perhaps persist it in some useful manor) is all well and good, until someone tries to stuff in data that isn’t valid. Users like to do things like this all the time, so I am going to attempt to protect against it from the beginning. Additionally, by setting up the mechanisms to test validation and perform validation, I should be able to keep a culture of enforcing these conventions throughout development.