meetscodingToday I was at Swetugg a Swedish .NET conference organized by the very awesome members of the Sweden .NET User Group also known as SWENUG. I thought it would be nice idea to write down my impressions of the different talks, the event itself and point you to some resources if you yourself find any of it interesting.
tl;dr Great small conference with interesting talks on Gamification, SOLID, TDD, Design, Akka.net, ApprovalTests, F# and Web Security.
The “barbarian meets” series are a collection of articles that intend to introduce and explain useful libraries, frameworks, tools and technologies in simple and straightforward terms. These new series will focus on the brand new framework from Rob Eisenberg the maker of Durandal and Caliburn frameworks which brings all the goodness of ES6, ES7 and web standards to your toolbelt: Aurelia
This week Rob Eisenberg surprised us all (or me at least xD) when he announced his new web framework Aurelia, a framework that allows you to start using the latest and greatest in JavaScript and web standards to build your apps today.
Dev Talk Monday is the series that brings you awesome dev talks every Monday
A couple of months ago I saw yet another amazing talk by Addy Osmani on the CSSConf EU conference where he uses Yeoman and other tools to make some magic and improve the performance of websites.
Check it out and follow Addy as he improves the performance of the CSSConf website step by step. You are in for a treat and you are going to learn a ton:
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.
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:
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:
TestCompleteTransaction(){
...
// Assert
Assert.That(socket.IsClosed());
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:
TestCompleteTransaction(){
...
// Act
var reply = socket.read();
// Assert
Assert.That(socket.IsClosed());
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.
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).
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:
(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!
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:
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).
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: