Intro

C# 8 unfortunately seems to be branching away from the standard .Net Framework and its not (fully?) compatible with the full .Net Framework, instead you have to use DotNetCore to get the benefits of it.

Intro

I came across Option FORCE ORDER a few months ago whilst looking into performance issues with a particular query, and thought it was worth writing down as I’d never seen it before and its quite useful.

Intro

The steady march towards learning F# continues. This time lets look at the option type, what it is, how it compares to nullables in C# and the basics of how you are supposed to deal with it. I originally started this post because I was dealing with option in a lot of my exploratory code, and the things I’ve read online about options implied they were special in some ways, but the further through I got the more I realise they are really just the F# version of the Nullable type in C#, its how they are handled functionally thats special.

I went to create a .Net framework F# console app as part of a larger existing .Net Framework solution, and found that the project dialog didn’t give me that option for a full .Net Framework project. I thought this was a bit weird, so did some googling and found that you have to install the F# Desktop Language Support pack.

The Problem

This is largely the same problem as the Test Data Builder, you have non trivial test data that needs repeated construction in many tests. I’m going to modify the example here though so it fits the use case of autofixture a little better, so we now have Lion and Rabbit Animal classes that we instantiate rather than just using a type on the Animal object:

Intro

This is just a really quick post on how to write async test methods in C# with XUnit and NSubstitute. Thankfully its quite simple these days, and is very useful to know as async calls become more and more commonplace.

Introduction

This is the first post on category theory terms, which is sort of like a mathematical version of design patterns in the functional world, but as you might expect they are at a much lower level than the OO design patterns.

Introduction

A little bit of magic from the functional world…

Intro

For my second post on F# I’m sticking with simple examples, and I’m going to write a really basic prime number calculator. Again I’m writing this in linqpad as an “F# program”.

lets(learn(fsharp(“”)))

How to..

This is quite frankly a bit weird so I thought I’d document it….

Intro

I got a message from the guys at NDepend asking me to try out a full version of their software, and I do like a good tool to simplify some of the more complicated development tasks, so heres a really quick post on what I found most useful on initial usage.

Intro

Linq in c# is a great abstraction, it massively reduces the amount of code to do fairly basic operations, using TypeScript doesn’t mean you lose this functionality, its just a little different to achieve many of the operations. In this article I’ll run through the basic Linq-To-Object operations, and how you can achieve similar results in TypeScript.

Intro

This was blogged about all the way back in 2007 by Nat Price here. Its one of my favourite patterns when tests start to get more complicated, I’m going to keep the examples simple in this explanation, but hopefully it should be easy enough to apply to more complex examples.

Intro

Dapper is an awesome Micro ORM and generally works the way I’d expect it to, and very quickly, but I fell into a little rabbit hole recently when using Dapper with async in C#, and I thought I’d document what I found out in a mini-post.

The Problem

There are loads of cases where this applies, but a simple one is: You have a target class that spawns a thread which updates a field with its result and you want to test that the result is set correctly. The really naive solution is to simply start the thread in your tests, do a Thread.Sleep() in there for the amount of time it takes for the result to be updated and check the result is there. This is bad in a couple of ways.

I’ve decided to write a bunch of patterns and practices up in a concise way that help to make unit testing in .Net a better, lower friction experience. Getting started unit testing can be quite painful, and its not usually until after you have written large numbers of tests that many issues come to light.

The Problem

Your class has a dependency on something that is outside of your control. A simple scenario for this is the DateTime object, its quite common to need to simulate a different “Now” in your tests to the one that the rest of the system uses.

The Problem

Anyone who’s written unit tests that have had to change will probably be familiar with this, objects that tend to interface to other classes tend to take in more parameters during the development cycle every now and then, if you’ve just newed up using the standard approach e.g.

I was intrigued to see how a table with System_Versioning enabled would behave if it had a rowversion on the primary table, and how it would get inserted to the history table.

Heres a distillation of a bunch of disparate information on async await in .Net, hopefully this will work as a fairly decent primer for the core async await functionality.

What do you do when you need to test a class that accepts a non-trivial dependency? Thats right, you just give up and don’t test it…

This is going to be an opinionated view as to the most efficient way I’ve personally found create a software design, heavily based on core OO & XP principles, allowing software to grow naturally, TDD and refactoring. It may not suit everyone, and I’m sure some people will disagree with it, but I’ve found these things to really help reduce unnecessary friction.

I’m going to try to do a few posts on test driven development in the .Net world. Yeah its been covered quite heavily already, but I think more information out there can only be a good thing, can’t it?

Unit testing is hard, you aren’t going to learn it overnight, you may not reap the benefits of it immediately, you may not have a code base that supports them, but persist and long term, the benefits will start to appear. This is especially true with code that is harder to test with more traditional methods. TDD is the next level of this, and tends to be even harder to apply at first, but can be a great benefit once you get the hang of it.

Comments imply the code does not speak for itself. Code with a lot of comments, usually has them because the code itself doesn’t adequately represent what its doing, and in most cases it could be changed so that it does describe itself correctly without a huge amount of upfront effort (apart from a few oddities to do with technological limitations, or odd requirements imposed on the code base).

So this is it.. blog post number 0. Not really sure how or what to write, but I’ve got a shiny new github pages repository… so lets have a go.