Barbarian Meets Coding Titlebarbarianmeetscoding

WebDev, UX & a Pinch of Fantasy

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 :)

Some Thoughts on the Awesomeness of Function and Object Composition in JavaScript After Reading JavaScript Allonge

Update 25-05-2015: Reginald Braithwaite has released his “sixth” version of JavaScript Allongé. The book has been greatly updated to include new ES6 (ES2015) constructs that make this book even more awesome. Go read it! or buy it

The place is Luleå, a place in the farthest reaches of the north of Sweden. The time is late, and it is cold outside, cold as it gets, -25°C. The world this far north is covered in snow, even the rivers, and the seas are frozen. A hard environment to live in, yet the perfect environment and time to read cozy in bed! :)

Last night I finished reading JavaScript Allongé on my beloved Kindle and I wanted to share with you some of the awesome things I learned, specially regarding function composition, functional programming and how to write beautiful, idiomatic, expressive and intentional JavaScript by taking advantage of its functional character.

JavaScript Allongé
Read on →