The Challenge:
Given you understand the value of test automation. Given you are handed a legacy application to maintain and enhance. Given the application is in ASP.Net Web Forms. When you try to add tests. Then you find that test-driven development is literally impossible.
Here's one solution, in long slide-style presentation:
Back in October I started playing around with a few technologies, resulting in my first code posted to GitHub: safnetDirectory. I must say that it is not the most impressive bit of coding that I've ever done. However, the urge to learn sometimes needs an unencumbered, no-strings-attached, digital canvas on which to exercise. That urge is requited through the experimentation and the lessons learned, rather than the completion of an opus.
The end result: I have a prototype of a mixed Angular.Js / ASP.Net MVC application that provides a simple directory and simple administrative functionality. And it is Hosted on Azure.
Desiring to learn about both Node.js (particularly as an API server) and ASP.Net Web API, I decided to throw one more technology in the mix and see which one is faster at relaying messages to a service bus, namely, RabbitMQ.
Time to turn that Node.js test green. In Part 2, I succeeded in publishing a message to RabbitMQ using Node.js. However, my automated test failed: the .Net test runner could not handle the generated message. Three key elements were missing, which are required for the MassTransit .Net library to interpret the message correctly:
Desiring to learn about both Node.js (particularly as an API server) and ASP.Net Web API, I decided to throw one more technology in the mix and see which one is faster at relaying messages to a service bus, namely, RabbitMQ.
And now, I finally get back to blogging about the ASP.Net Web API code that I wrote for this head-to-head comparison of REST service and message bus integration. The official tutorials were my guide for Web API, and as with the test runner in part 1, I used MassTransit as a convenient library for publishing from .Net code to RabbitMQ. Owin was my solution for self-hosting the web application.
Many social websites, and web-based applications, have a notification process where the server sends a signal back to the browser, informing that particular user that there is a message. "You've got mail," as America On-Line used to say it. Consider the picture below, from Twitter, which shows that I have one new notification. That number increments automatically when a new notification arrives, without having to reload the full page. How does that work? Well, this blog post doesn't try to answer that directly. In fact, it is simply a collection of notes pointing out how to use Microsoft's SignalR technology to achieve this.
Isolating code from dependencies is crucial for developing small, well-defined, easy-to-understand tests. And it is an absolute must when those dependencies call external resources, such as a database, filesystem, or heavy-duty component (e.g. for interacting with office docs). But how do you introduce isolation in new unit tests for legacy .Net code? Well, that depends... and I have a flow chart and brief notes to help you figure it out.
Desiring to learn about both Node.js (particularly as an API server) and ASP.Net Web API, I decided to throw one more technology in the mix and see which one is faster at relaying messages to a service bus, namely, RabbitMQ.
This is part two in a series. Part 1.
Let's start with Node.js. I already let you in on the fact that formatting a message for .Net to pick it up is tricky, and I won't get into the detail of that yet. For now, let's concentrate on setting up node.js and communicating with RabbitMQ. We'll get the finer points of interacting with .Net later.
Desiring to learn about both Node.js (particularly as an API server) and ASP.Net Web API, I decided to throw one more technology in the mix and see which one is faster at relaying messages to a service bus, namely, RabbitMQ. Naturally, such a test does nothing to prove that one framework is generally faster than the other, but it is a fun exercise nonetheless.
Thus the challenge is this: accept a string message via POST, forward it to the
service bus, and return HTTP Status Code 202 (Accepted) along with an
acknowledgment that repeats the original message. Both REST services should be
self-hosted; free from additional cruft like error-handling*; and should utilize
an url like http://localhost:port/Message/mymessage, where "mymessage" is the
string to be sent across the bus.
Developed to help introduce key topics in Test Driven Development, for new and veteran developers alike. Some examples are language-specific (C# / MSTest / Moq), but the principles apply to any object oriented language.
Recently I have been looking at ServiceStack's OrmLite "Micro ORM" as a light-weight alternative to Entity Framework. It is relatively easy to use and very powerful, with capability for both code-first and database-first development. After learning the basic interaction, it was time to flip back into TDD-mode.
And then I found quite the challenge: I wanted to write unit tests that insure that I'm using OrmLite correctly. I was not interested (for the time being) in testing OrmLite's interaction with SQL Server itself. That is, I wanted behavioral unit tests rather than database integration tests. Time for a mock. But what would I mock? This ORM framework makes extensive use of extension methods that run off of the core IDbConnection interface from the .Net framework - so it would seem that there is no way to take advantage of Dependency Injection.
