jimmy keen

on .NET, C# and unit testing

Using Git with Powershell on Windows

November 10, 2015 | tags: git windows powershell posh-git

This will be a quick guide on how to set up Powershell with Git on Windows.


  1. Powershell
  2. Git for Windows
  3. Git credentials store

Download and install files above. Make sure Git bin directory is added to your PATH environmental variable. Credentials store are not really required but I’m pretty sure you do not want to type your login details with every push or pull, right?


Just as with any console application, Git offers a way to streamline your work with aliases. Rather than typing

> git add -A

> git commit -m "Added config file"

You can simply type

> git c "Added config file"

This of course goes further than that considering we have Powershell at our disposal. For example, you can easily create alias like this:

> git config --global alias.logby "!f() { git log --author='`$1'; }; f"

> git logby Jimmy

We create f function and execute it straight away. You can read more about this approach at “Git alias with parameters”. When setting such alias from powershell itself, make sure to escape $-variables with ` (grave accent symbol), otherwise powershell will try to insert variables which are not there.

You can see some more aliases here.

The Posh

A neat little extension offering git comands completition and making your Powershell look like this:

posh-git powershell highlighting

Posh-git can be installed from powershell:

> (new-object Net.WebClient).DownloadString("http://psget.net/GetPsGet.ps1") | iex

> Install-Module posh-git

If your powershell compains that your execution policy is restricted, make sure to unrestrict it with:

> Set-ExecutionPolicy RemoteSigned

It’s great we can see current branch name. It’s also great that we can see whether there were any modifications. But I’m not a huge fan of having all the details of changed files, untracked, stashed and so forth. I would rather have this:

posh-git powershell simplified highlighting

A simple indicator telling me what branch I am on and what’s the status (* - pending changes, - synced with HEAD, - ahead of HEAD).

Behavior described above can be achieved if we modify posh-git code, namely GitPrompt.ps1 file. You can find this file location in one of your powershell modules directories (check $env:PSModulePath variable). You can use the files from my repository:

And that’s it. Enjoy your brand new Git + Powershell experience!

Refactoring unit tests for readability

June 07, 2015 | tags: c# unit-testing refactoring

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. - Martin Fowler, 2008

The code you produce will be read. The “brillant” class you have just written and forgotten might sit idle for many months. Then it breaks. It’s Friday evening and hotfix is needed right now because crucial invoicing procedure is generating weird, negative invoices for no reason!

Your poor colleague, Joe, is assigned to this dreaded task only to find your class. With elaborate algorithms solving simple tasks, because optimization1. With rarely used LINQ method. With neat, little code trick. With bit of “hackerish” list operations you had then learnt from some cool blog.

Sure, the implementation worked great. Unfortunately, not for Joe. He most likely understands nothing of it. Not because he has brain freeze or is slightly slower. It is because you had produced unreadable, unmaintainable ball of mud.

Why readability matters

Joe would have been just fine if you had kept your solution simple. Saved cool tricks and hacks for your pet projects at home. Didn’t optimize prematurely. Instead, focused on solving problem at hand and making sure your code is as simple to follow as possible. It is invaluable in situations like the one described above.

Now… how do you improve readability of your code? To discover that, we’ll take a look at the ExportTaskScheduler class, solving one specific business requirement – scheduling export:

public void ScheduleExportTask()
    var futureTask = new FutureTask
        TargetIdentity = "ExportTask",
        CommandType = typeof(ExportCommand),
        PreparationDate = timeService.Now().AddSeconds(10),
    var launcher = new Launcher
        LaunchTime = timeService.Now().AddMinutes(10),

    futureTaskScheduler.ScheduleFutureTask(futureTask, launcher);

That’s all there is. This code is fairly simple and readable. Method has well-defined, single responsibility (schedules export2) and is only few lines long. Anybody reading it should be able to tell what’s going on almost immediately. Readability goal has been achieved. Or… has it?

Let’s take a look at its unit test:

public void TestScheduleFutureExportTask()
    var taskScheduler = A.Fake<IFutureTaskScheduler>();
    var timeService = A.Fake<ITimeService>();
    var scheduler = new ExportTaskScheduler(taskScheduler, timeService);
    A.CallTo(() => timeService.Now()).Returns(10.May(2015).At(13, 33));


    A.CallTo(() => taskScheduler.ScheduleFutureTask(
            A<FutureTask>._, A<Launcher>._))
        .WhenArgumentsMatch(args =>
            var futureTask = args.Get<FutureTask>(0);
            futureTask.PreparationDate.Should().Be(10.May(2015).At(13, 33, 10));

            var launcher = args.Get<Launcher>(1);
            launcher.LaunchTime.Should().Be(10.May(2015).At(13, 43));

            return true;

This code is certainly not as readable as implementation one. Why is that so? Unfortunately, unit tests are often treated as “second class citizen”, a code where regular practices and patterns don’t apply. This is a mistake. You will often find test methods without descriptive name, spanning multiple screen, weird mocks usage, cryptic variables naming – all developer’s careless attitude visible through code. Just as if unit test was some sort of different, less important code. It is not. It is production-level one, just as any other.

Without further due, let’s go over the issues one by one.

1. Test method name

The TestScheduleFutureExportTask tells us nothing. This is bad because method name is first thing we will see (especially when test fails) and it’s the name which should give us brief overview of testing scenario (so that we get to know what we are dealing with quickly). Using one of the popular naming conventions we arrive at something closer to ScheduleExportTask_SchedulesCorrectTask_10MinutesFromNow.

2. Variables names

Since we deal with two schedulers, high level one (scheduling business process) – ExportTaskScheduler, and low level one (scheduling code commands described by some objects) – FutureTaskScheduler, we should pay extra attention to how these two variables are named. The current choice (taskScheduler and scheduler) is rather poor as it is harder to discover which is which. Rule of thumb is to keep the variables names long, without any “smart” abbreviations. In the long run, exportTaskScheduler is an immediate tell, while scheduler, taskScheduler, tScheduler or exTskSchd are not.

3. Dealing with time

We use FluentAssertions syntax to neatly create DateTime instances but truth to be told, the exact value is irrelevant in this test. We need some point in time because we assert how other values relate to this given point (task is scheduled 10 minutes from now). We are better of with hiding exact value, for example in static field:

private static readonly DateTime Now = 10.May(2015).At(13, 33);

Then, our asserts are much more verbose:


4. Asserting values

Since this is the rare test of verifying whether some other component was called (with correct parameters) and we are already doing asserts inside WhenArgumentsMatch the simplicity has taken a hit. What we could do is extract the assertions to separate methods. Our test now looks like this:

public void ScheduleExportTask_SchedulesCorrectTask_10MinutesFromNow()
  var futureTaskScheduler = A.Fake<IFutureTaskScheduler>();
  var timeService = A.Fake<ITimeService>();
  var exportTaskScheduler = new ExportTaskScheduler(futureTaskScheduler,
  A.CallTo(() => timeService.Now()).Returns(Now);


  A.CallTo(() => futureTaskScheduler.ScheduleFutureTask(
          A<FutureTask>._, A<Launcher>._))
      .WhenArgumentsMatch(args =>
          IsFutureTaskCreatedCorrectly(args) &&

It is good as it is but there are few more things we could do. They might not be as beneficial in this simple case but as the number of test cases grows, they will make a difference.

5. Extracting instances creation

For any test case, the way system/class under test instance is created is most likely irrelevant. What matters is easy access to such instance and clear, intuitive name (and we’ve already dealt with that). To put that noise away, we can move such preparation steps elsewhere. For example, to NUnit’s SetUp method where each instance is created and stored in class field:

public void InitializeComponents()
    futureTaskScheduler = A.Fake<IFutureTaskScheduler>();
    timeService = A.Fake<ITimeService>();
    exportTaskScheduler = new ExportTaskScheduler(futureTaskScheduler,

This way, the arrange part tells that current time is this and this, which is the only relevant information.

6. Verbose arrange

…which could be improved further. How? By wrapping it in a more verbose method, like:


The more test cases we got, the more beneficial such verbose arranges get. Similar thing can be done to assert part but since it will be different for different tests, there is little gain (we won’t be able to reuse such verbose assert). The final version of unit test might look like this:

public void ScheduleExportTask_SchedulesCorrectTask_10MinutesFromNow()


  A.CallTo(() => futureTaskScheduler.ScheduleFutureTask(
          A<FutureTask>._, A<Launcher>._))
      .WhenArgumentsMatch(args =>
          IsFutureTaskCreatedCorrectly(args) &&


Readability is important. Simple, easy to understand code is important. Somebody is going to read our work one day, maybe in a big hurry. We don’t want to make their work harder.

To learn more about practices similar to the ones presented in this post, I recommend Robert C. Martin book, Clean Code, and his training videos based on the book (these can be found online).

  1. Premature, of course.

  2. One might argue that there’s hidden responsibility in creation of objects (FutureTask and Launcher). However, these are DTO-types and we should look at them just as we would look at string, int and similar types.

Getting started with JavaScript unit testing – Node, Jasmine, Karma and TDD on Windows

March 12, 2015 | tags: unit-testing javascript karma jasmine node.js windows


I’m working on a .NET regex tutorial and I thought it would be nice to have sort of interactive-try-it-yourself examples embedded within blog post. This sounds like a job for JavaScript, right? Simple enough. The only issue is, my JavaScript knowledge and experience are virtually non-existent. What do I do? I’ll start with a test!

JavaScript and unit testing

What are the unit testing options when JavaScript is concerned? To start we need two things - test runner and assertion library. This StackOverflow question provides decent overview on what’s available. It turns out all we need is Jasmine which is both test runner and BDD framework, supporting BDD-style of writing tests (or rather specs).

Installing Jasmine on Windows

  1. Download and install node.js (it comes as standard Windows .msi installer )
  2. Once it’s done, type the following in the command line to see whether node’s package manager (npm) was successfully installed (we’ll use npm to download further modules):

> npm --version


Now we only need few more modules: Yeoman, Bower and Generator-Jasmine. Type following in console:

> npm install -g yo

> npm install -g bower

> npm install -g generator-jasmine

The -g switch tells npm to install packages in node’s global modules directory (rather than locally within your project’s directories).

To finalize testing environment setup, we need to scaffold Jasmine’s tests directory. To do that, we’ll navigate to project directory and use Yeoman’s yo tool:

> yo jasmine

This will create test directory with index.html and spec/test.js files, which will be of your primary interest.

Running first test

The index.html is Jasmine’s test runner – open it in browser and your tests will run. “How? What tests?” you might ask. Let’s take a quick look and index.html:

<!-- include source files here... -->

<!-- include spec files here... -->
<script src="spec/test.js"></script>

We simply need to reference our implementation and test files:

<!-- include source files here... -->
<script src="../regex-highlighter.js"></script>

<!-- include spec files here... -->
<script src="spec/regex-highlighter-tests.js"></script>

What’s next? First test, obviously. Since this is super-fresh environment our first test for highlightMatches function is going to be trivial, requiring the implementation to only return value:

'use strict';

(function () {
    describe('highlightMatches', function () {
        it('should return "Success"', function () {
          expect(highlightMatches('x', 'y')).toBe('Success');

Explanation of Jasmine’s methods and BDD-style can be found at Jasmine Introduction page. Without further due, we add equally simple implementation of highlightMatcher function, refresh index.html and Jasmine is happy to announce that our first JavaScript test is very successful one:

First successful JavaScript test with Jasmine

Introducing Karma

Our current setup is up and working and we might just as well be done here. But there is one more thing that will help us greatly when developing JavaScript code – Karma. It is a test runner which watches over our files and runs all tests whenever we make any changes in source files. Perfect match for TDD/BDD environment! You can view introductory video at Youtube (14:51) (don’t get confused – tutorial talks about Testacular, which was Karma’s original name while ago).

To get it we need to execute the following (the karma-cli is Karma’s command line interface module):

> npm install -g karma

> npm install -g karma-cli

Next, navigate to project directory and initialize configuration. Karma will “ask” few simple questions and basing on your answers it will generate config file (js.config.js):

> karma init jk.config.js

Which testing framework do you want to use ?

Press tab to list possible options. Enter to move to the next question.

> jasmine


What is the location of your source and test files ?

You can use glob patterns, eg. "js/*.js" or "test/**/*Spec.js".

Enter empty string to move to the next question.

> ../regex-highlighter.js

> spec/regex-highlighter-tests.js


Configuration is ready. All that’s left to do is simply run Karma, passing configuration file name as argument:

> karma start jk.config.js

Everything should be find and we’ll be greeted with message similar to the one below:

Successful Karma setup

Modifying test to make it fail will get noticed immediately:

Failing test


To get started with JavaScript unit testing you need to:

  1. Install node.js
  2. (optional) Install Jasmine, Yeoman and Bower npm install -g yo bower generator-jasmine (this trio isn’t needed when you use Karma – Karma will take care of dependencies on its own)
  3. (optional) Scaffold Jasmine test directory yo jasmine
  4. (optional) Run first test by opening Jasmine’s index.html
  5. Install Karma npm install -g karma karma-cli
  6. Configure Karma karma init <config>
  7. Start Karma karma start <config>