Barbarian Meets Codingbarbarianmeetscoding

WebDev, UX & a Pinch of Fantasy

Learning Test Driven Development With Kent Beck

With Barbaric Book Reviews I bring you interesting reviews and useful insights from awesome books that I have read. I also bring myself the magic of everlasting memory so that I don’t forget these tidbits of knowledge as I grow old and wither.

I have been doing TDD (Test Driven Development) for the past 4 years and yet I didn’t know that Kent Beck had written a book expressly devoted to teaching TDD. So image my surprise as I was browsing the interwebs for my next book-ish victim and I stumbled upon Test Driven Development By Example.

Test Driven Development By Example

This is one of the most pedagogic and hilarious programming books that I have read. Imagine that you had the chance to learn TDD sitting beside Kent Beck in a pair programming session. Cool right? Well that’s how the book feels like. You and Kent will program side by side and test drive a multicurrency system in Java, and a testing framework in python (and yes, you will test drive the testing framework while using it to run your tests #inception #ftw xDDDD). And to wrap it all up, Kent summarizes and reflects about useful test patterns, refactoring heuristics and useful design patterns for both testing and refactoring.

I leave you with a quote that describes who TDD is for:

(...)TDD rests on a charmingly naive geekoid assumption that if you write better code, you'll be more successful. TDD helps you to pay attention to the right issues at the right time so you can make your designs cleaner, you can refine your designs as you learn.

(…) TDD is also good for geeks who form emotional attachments to code. One of the great frustrations of my young engineer’s life was starting a project with great excitement, then watching the code base decay over time.

(…) TDD enables you to gain confidence in the code over time. As tests accumulate (and your testing improves), you gain confidence in the behavior of the system. As you refine the design, more and more changes become possible. My goal is to feel better about a project after a year than I did in the starry-eyed beginning, and TDD helps me achieve this.

Update 22th January 2015: So I was having a shower and my mind started wandering towards some of the interesting and surprising things that I had learned from this book that I hadn’t thought of or read about before. And I thought it would be nice to share them with you:

Start writing tests from the assert.

I have always followed the AAA (Arrange Act Assert) and I don’t know, it feels super natural to start from the beginning, so this was a super interesting proposition, to start from the end instead. Kent assures us that it has a simplifying effect, that it will help you focus on one problem at a time. He uses the example of communicating with a system over a socket. When we want to test that, what we want to achieve is to have obtained some data, and to verify that the socket is closed, so we write:

    // Assert
    Assert.That(reply.Contents, Is.EqualTo("abc"));

And then we ask ourselves, where does the reply come from? and answer A socket of course, so we write:

    // Act
    var reply =;
    // Assert
    Assert.That(reply.Contents, Is.EqualTo("abc"));

And we continue asking questions until we have our test. I have tried it a couple of times and I have mixed feelings about it. But perhaps the problem is the lack of familiarity XD.

Using TDD and Unit Testing To Learn New Libraries Or Frameworks

Another interesting concept was the use of TDD to teach yourself to use new libraries. The idea is to go get a new library that you want to learn, Install-Package LibraryXYZ and you start writing tests against its API and exploring how it works.

Alternatively you could reuse those tests that you’ve written to learn the library to make sure that future updates play well with your own codebase (no unexpected breaking changes).

Red Green Ref… Remove Duplication

It is very remarkable that when Kent defines TDD he starts not by talking about the famous Red/Green/Refactor but about the two rules of TDD:

  1. Write new code only if an automated test has failed
  2. Eliminate duplication

(which then derives into the TDD Mantra of Red/Green/Refactor). And what it is very interesting about it, is that it is not only the duplication that you refactor out of your design in your production code, but oftentimes the duplication between your tests and your code. As you go through the TDD workflow you go removing this duplication: start writing a test, write the production code that provides the easiest/fastest solution to pass the test, which will probably be a hardcoded value and thus the duplication between test code and production code. So you remove the duplication to continue the TDD workflow until the arrival to the desired solution with no duplication, unicorns and rainbows. Another cool point of view that I hadn’t reflected about.

And that’s it! Have a nice day!

Why I write unit tests and why you should too

A friend from work started a conversation thread about whether or not there is value in unit testing and I wrote a pretty long response. And then I thought to myself… hmm, that could actually be a blogpost!! And so here we are, getting more value out of these precious keystrokes. Here it is the slightly rewritten version of why you should write unit tests…

I am definitely a pro unit testing kind of guy. I see it like this, in order to ensure that your code works as you expect you need to test it. In the olden days you may have done this manually, you may still test some parts of your application manually like the UI (parts where automated testing can be/feel too expensive), but the most cost-effective way to test is by writing automated tests, and particularly unit tests (test a unit of work/code in isolation). For me it’s usually about the short feedback loop, the instant and unequivocal knowledge that the code that I have just written works.

There is quite a score of benefits you can get from writing unit tests. Unit tests:

  • ensure the code behaves as you want it to behave
  • are fast to write, fast to run and provide a very short feedback loop to let you know that your code works
  • help you find bugs with super-high granularity (if a unit test shows a bug, you pretty much know which class it is in, you don’t need to go throw all classes nor debug it, that’s priceless)
  • force/encourage you to write very simple classes and increase modularity and separation of concerns (because writing unit tests for fat, complex classes with tons of collaborators is horrible and we have a natural tendency to avoid pain)
  • increase developer confidence to refactor
  • act as documentation for my future self and other developers
  • ensure that a bug/defect never happens again (regression test)
  • ensure that you don’t break something that was previously working

They are also a cornerstone for Agile development practices, without unit tests (and of course other types of automated tests) it becomes very hard to succeed with continuous integration and continuous delivery. How can you have confidence in that your application works as you expect if you have nothing to prove it? This becomes even more apparent when you have bigger application and the number of developers collaborating increases. (Although there’s people that thinks that the solution to manage complexity is to not write big applications in the first place xD). Anyhow, unit tests, and other types of automated tests, are one of the most basic fundamental elements that allows facebook or github developers to deploy to production several times a day.

At the same time, writing unit tests does not imply that you are going to catch all bugs in the universe with them or that you shouldn’t write other types of automated tests: acceptance tests, integration tests, end-to-end tests, UI tests. Different types of test have different costs/benefits and different “bug profiles” associated to them. Generally, high-level tests will provide a truer representation of the current state of your application which means high value to me, but they will typically have a higher cost to write and they will take a longer time to run (more setup, more cleanup, can be more brittle as well). You are also going to need to be ready to put some time to write unit tests and expect that you are going to write at least as much test code as production code, and see it as an investment that you can start taking advantage of instantaneously and into the future for ever and ever XDDD. Fortunately there are many tools that make writing unit tests easier and less of a hassle: testing frameworks (NUnit, MSTest, mbUnit, SpecFlow, NSpec, etc) , mocking libraries (RhinoMocks, Moq, FakeItEasy), testing utilities (AutoFixture, AutoMoq, etc), continuous test runners (NCrunch, MightMoose, etc), and so on.

If you want to be serious about testing (and about writing clean code), it is very important to keep your eyes open and exercise your awareness when writing unit tests. When you write unit tests you are exercising your own code, and you get a very good chance and are in a very good position to feel the pain, to experience whether your design is easy to use or a nightmare. TDD it is particularly interesting in this regard, you get to be the first person to use your own code. Do you feel pain when using your code? Fix it, refactor it, redesign it till you get to something that is pleasing. Do you update some implementation and break a bunch of tests? Perhaps you tests are too specific, focus on testing behavior, the appreciable results of exercising a piece of code. Test, reflect, improve (your tests and your production code).

Some Awesome Resources to Learn About Unit Testing and TDD


Articles and blogs


And those were some thoughts from the top of my head on why I think that you should write unit tests :).

Other interesting articles on the subject:

Barbaric Tip of the Week: Improve Your Code Typing Skills with

Barbaric Tip of the Week is a weekly series whose main purpose is to share tiny bits of knowledge that I find specially useful and interesting.

A couple of years ago I started using vim and I realized that my typing skills did not cut it - I did not practice touch typing but my own deformed version of typing born of using the computer from an early age mainly to play video games and chat on IRC.

I didn’t despair, not yet at least. I decided to switch keyboard layout, nothing drastic, just from a QWERTY Swedish keyboard layout to a US layout (noticing that it was much easier to type parens, semicolon and other programming keys). I also started learning proper touch typing with the typingweb - great web app for typing btw. For the next four weeks I practiced touch typing 2 hours before going to work and 2 hours before going to sleep. The first two days were horrible, I was writing like 10 WPM and thinking to myself all the time: “Come on Jaime! You can do better than this!”. It got better afterwards but that wasn’t the worst, after a couple of weeks I had sooo much pain in my wrists for the excessive typing (before, during and after work) that I couldn’t lift weights at the gym. For the next 6 months or so I wouldn’t do any curl exercise.

Today, almost two years after, I am pretty decent at touch typing and at vim-ming. I am still not as fast as I used to be but I can do 70-80 WPM relaxed when typing text. However, touch typing text is not the same as typing code. And that’s why is so awesome:

Imagine practicing typing code by using the source code of your favorite open source projects (or any other source code for that matter). Read and learn cool stuff from open source, and at the same time improve your typing skills with pesky characters such as ], }, ), *, =, etc. That’s what is all about. Cool right?

Typing some code

100 Things Every Developer Should Know About People

With Barbaric Book Reviews I bring you interesting reviews and useful insights from awesome books that I have read. I also bring myself the magic of everlasting memory so that I don’t forget these tidbits of knowledge as I grow old and wither.

Some months ago my good friend and UX sorcerer Erik Claesson recommended me yet another UX-related book titled 100 Things Every Designer Should Know About People by Susan Weinschenk. I finished it a couple of days ago as I was flying back to Stockholm from the frozen confines of the north of Sweden (Luleå).

The world is frozen brrrrr

I thought it would be interesting to write a short article to summarize the things that I have learned from it. Some of them I already knew, since there are some recurring topics in UX and psychology literature, but some repetition never did no harm to anyone.

Read on →

Goodbye 2014, Hello 2015!!

Following the now tradition of the yearly reflective summary, it is time for the wrap-up blog post on what I achieved on 2014, which were my biggest #fails and what I am planning to do in 2015. Here it goes!

In 2014 I:

  • Had a beyond awesome year with my beloved Malin filled with awesome moments like our trip to Japan and moving from Linköping to Stockholm.
  • Started my own company and built a website as a company hub.
  • Had a great year working as a software developer at Medius where I got to continue developing my skills as a software developer and working with great colleagues.
  • Got a new job in Stockholm at an awesome company, Active Solution, and I am looking forward to get started in January.
  • Wrote 32 blog posts this year, and also recorded my first video ever.
  • Created several new presentations this year on RavenDB, Knockout.js components, developer productivity, LESS, Ionic and REST, and gave two talks in our local .NET user group in Linköping.
  • Read 50 books on programming, business, fantasy, sci-fi and self-improvement, almost a book per week of the year.
  • Went to a hackathon and built pendel panda, an awesome experience both for the chance of working with a great team with very diverse skills and for being able to work with Ionic and dip my toes into the hybrid mobile development scene.
  • Did lots of learning, this year focusing on:

    • JavaScript and its more functional flavors
    • Angular
    • Ionic, PhoneGap, Cordova and hybrid mobile development
    • REST and Hypermedia
  • This is my third year since I quit smoking and I am still going strong.
  • Led a healthy lifestyle with a great work-life balance, lots of training (running and weightlifting) and healthy eating. It got a little screwed towards the end of the year when I got a shoulder injury but I’m back now biatches! :)

Some of my biggest #fails, things that I really wanted to achieve but I didn’t were:

  • I did not write a book
  • Even though I started a company, built a website for it, and started developing a couple of new features for quiz4couples I never got anything finished, nor built any new product at all, which sucks. This was a BIG fail for me.
  • Didn’t invest almost any time in improving my design/art skills

If I had to summarize 2014 I would call it a year of big changes with moving to Stockholm after living the last 4 years in Linköping and starting a new job at the center. I think I spent a lot of energy and time in both of these milestones, but in spite of this all I still got a lot of things done.

In 2015 I want to:

  • continue investing in my great relationship with Malin :)
  • develop at least one product with my company
  • write a short book
  • become an even more awesome software developer and specialize more in front-end development
  • blog smarter, being more consistent developing a writing habit instead of doing one-time-writing-marathons as I do know almost a 80% of the time.
  • invest more time in my drawing/design/art skills
  • continue investing in a healthy lifestyle

but above all I want to become a finisher, I want to spend this year focusing on strengthening the habit of finishing the things that I start.

Hope that you also had a great 2014 and that an even more awesome 2015 awaits you! Let’s get started kicking some ass!… and finishing the goddamn stuff :)