Thursday, July 24, 2014

Designing with Tests talk at IASA

Last week I had the pleasure of presenting at the local IASA (International Association of  Software Architects). I talked about how to use unit tests to design software and the role of the architect when using TDD.

It was a good talk with a lot of good questions from the audience. We’ve discussed when to use TDD and its limits and I got to show a full demo of developing a real application using TDD from scratch.

Afterwards I’ve attended a panel with Gil Zilberfeld and Lior Israel where we talked about TDD, BDD, how the architect can use those methodologies as part of his architecture handout to the development team and answered questions from the audience.

The session was recorded and published on YouTube (in Hebrew)

I’d like to thank IASA for this opportunity - I enjoyed giving this talk and I hope I get more opportunities to discuss it in the future.

Monday, June 30, 2014

TDD != Unit Tests (and vise versa)

It’s been a busy week that started somewhere three months ago and I’ve missed most of the whole “TDD is dead” argument.

I finally had some time to sit and watch the discussions on the topic between Kent Beck, Martin fowler and David Heinemeier Hansson.

If you’re interested in unit testing and TDD (and you should be) - this is a great opportunity to listen to great minds and learn what they think of the subject – I know I learnt a lot and plan to continue watching till the end (there’s .

Although I only got as far as the 2nd part–  I can see a pattern emerging – it seems that every argument for or against TDD is actually about unit testing.

It seems that the discussion is not about “why TDD is good/bad” but a discussion about whether or not use unit tests (use!), the unnecessary layers of abstraction they might introduce (the dreaded design for testability) and how people completely miss the point by tying themselves to implementation by over mocking their application.


A quick search in the internet showed me why at least one of the participants think so:


DHH has a good point – obviously how you write unit tests effects directly the way you practice TDD.

But there’s more to TDD than just writing unit tests just like there’s more to software development than writing code. I always argue that the unit tests are a byproduct of TDD and not the other way around – we use unit test to drive our code design, and at the end of the process we’re left with a pretty decent test coverage that can prevent regression but we’re also left with a very specific design – which is the objective of the whole process.

Knowing how to write good unit tests is crucial in order for TDD to succeed – but you also need to have good coding practices, know how to refactor your code and a thing or two on software design in order to be successful.

Because TDD is not about writing unit tests – it’s about design. The tests are there to help with that and theoretically can be deleted as soon as you’re done writing your code – although I’m yet to find someone who would give up the benefit of having the unit tests.

I hope that the next 3 parts of the hangout would concentrate on TDD as a design methodology and leave the unit testing discussion behind.

Thursday, June 26, 2014

My DevGeekWeek sessions

I’ve had fun today at DevGeekWeek where I got to talk about writing clean code and unit testing best practices.

I’d like to thank the participants of today’s seminar – you were a great audience and I enjoyed speaking with you and learning about your experience with Agile, unit testing and writing code.

Just in case you weren’t there today – here are the slides:

Monday, June 09, 2014

DevGeekWeek 2014

Those you know me (or read my blog) know that I’m passionate (with a capital P) about software development, clean code and of course unit testing.

And I’m happy to be given the opportunity to talk about these topics as part of The DevGeekWeek 2014 conference.DGW_addmails_down

The DevGeekWeek is a week of all things software development and is scheduled for the 22-26 of June and will be held in the Daniel Hotel in Hertzelia (Israel).

CodeValue is responsible for the Extreme .NET with C# track with great speakers including yours truly.


I’ll be delivering two sessions on the last day at the Code Quality, Testing & Automation with Visual Studio & TFS seminar:

We’ll start with a session by Alon Fliess about Architecting Code For Quality, then my colleague Haim Kabesa with Building Coded UI Tests with Visual Studio and Test Manager and after launch I get to present two of my favorite topics:

  • Writing Clean Code in C# and .NET
  • Building Unit Tests correctly with Visual Studio 2013

I’ll talk about code and readability, avoiding stupid bugs and unit testing for the .NET developer – using Visual Studio to make it all happen.


See you there!

Monday, May 26, 2014

What’s wrong with TDD

A while  ago I was asked to talk about the problems of using TDD – being me I’ve decided to do the exact opposite, this session was names “what is wrong with TDD”.
I felt that one of the major issues is that TDD looks weird, it’s counter-intuitive, and convincing developers to actually try it hard and requires a mental leap of faith.
And so I’ve created the talk aiming to help those developers who wish to teach their team a new methodology (because TDD is a tool not a religion) and need “ammunition”, answers for their co-worker’s questions, suspicions, rants and excuses for not using Test Driven Development.image
Since then I got to present this talk several times both as 15 minutes  lightning talk as well as a 2 hours session (and anything in between) –  and so I thought to write a blog post that would summarize these sessions on the topic of reasons of not using TDD and why they are wrong…

I don’t like tests/I don’t have enough time

I believe TDD and “unit tests” has been done a great injustice by not giving it a cooler name – preferable one that doesn’t have the word “test” in it – because it’s a PR disaster!
A few years ago I have been invited to talk about “TDD in the real world” at a local user group – around the half hour mark one guy who set at the front row raised his hand and asked me – “does that mean that developers write these tests?”
It’s easy to understand why some developers think that “tests” are not their job – after all they are called “developers” and not “testers”.
Usually this lack of enthusiasm of writing these strange little tests hides behind a more “acceptable” argument – I really want to write unit tests (wink, wink) but unfortunately I do not have enough time to do so – obviously such developers are developing the only project in the world that have a deadline.
There is truth in the “I don’t have enough time” argument – writing code with unit tests takes more time then writing code without, I call this development phase as the “hitting keyboard phase” and it could take from 15% to 35% (!) more time – even more on hard to test projects.
But the benefits of TDD are much greater and in fact using TDD we reduce the time it takes to get your code to the client (the one who uses your code) by having less bugs (around 40% to 91% less bugs) and more maintainable code. I wrote about it back then when I worked at Typemock  - The Cost of Test Driven Development.
[Realizing quality improvement through test driven development: results and experiences of four industrial teams]

In conclusion – Writing tests costs time, but overall development takes less time. It’s an investment and like all investments you can choose not to make it – it’s up to you. Just make sure you’re aware of the cost of that decision.

Writing tests before the code is counterintuitive

Since most developers cannot predict the future – how can you know which tests to write before actually writing the code?
I think there are two real reasons not to want to write tests before the code:
It requires leaving you comfort zone
Up until this point you were taught to think of all of the possible scenarios and find the optimal solution, using the power of design methodologies learnt during a long and successful career. And now you need to “not think about design” and develop one test at a time – an it’s suppose to fail!
Planning for failure
Deep down it’s hard to see something I wrote break – even if it’s just for a little moment. And so writing a failing test a.k.a the first step of TDD is hard for some.
What would a developer not willing to try (exit comfort zone) do? Write unit tests – after writing the code and try to sell this practice as TDD.
This is usually a bad idea – most experienced TDD practitioners can tell whether or not the unit tests has been written before or after the code. And writing unit tests for existing code is harder, much harder than writing the tests before.
A developer who write unit tests after writing his code is missing the whole point – TDD is a design methodology – the unit tests are just a by-product of the process.
It’s about growing your code writing only what you need and about emergent design and not about writing unit tests.

Not everything is testable

This is actually a good reason – when this is really the case.
There are pieces of code that cannot be run as part of unit tests. I’m not talking about bad written code – there are ways to handle these. I’m talking about UI, video streaming, and some closed architectures that make unit testing almost impossible.
Needless to say if you cannot write unit tests – you cannot use TDD (duh).
But make damn sure that this is the case – because hard to test is not untestable:
  • By following MV* patterns (MVP, MVC, MVVM etc.) you can still test the UI business logic and drive its design using TDD.
  • Mocking frameworks are there to help you stub/mock external dependencies (Web, DB, 3rd party components)
  • When all else fails write integration tests (yes – as part of TDD)
In fact there are many ways to test this so-called “untestable code”, books have been written about it and there’s a plethora of tools to help with unit testing less than trivial code.
In the end you might not have 100% test coverage (whatever that means) but at least you’ll be able to easily maintain and develop your business logic.

TDD locks design

I get this usually half way through teaching a unit testing/TDD course - what would happen if we write all these tests and then need to change the design?
It feels like a big waste of time re-writing tests over and over again just because code (being code) was changed to fix a bug or add functionality.
Once I even got a complaint by a co-worker that “writing the code took one hour but fixing the tests took half a day”.
The good news is that there are principles of good test design that would prevent having to change your tests every single code change – this is where one assert per test and don’t test private methods come from (and there are many others).
Ideally only requirement change or a bug should cause your tests to break. This is not always the case but after writing a few hundred tests, reading a good book (or blog) you’ll find what to avoid and how to reduce the cost of maintaining your unit tests.
Good tests are simple, robust and easy to update if the need arise – bad tests get deleted and replaced.


TDD is not perfect:
  • It requires time investment
  • Seems counterintuitive at times
  • A new skill to learn
  • It might not work for all scenarios
But none of the reasons above is a good reason not to give it a try – it’s a powerful methodology that helped me combat “analysis paralysis”, create robust, maintainable code and there’s the added benefit of the resulting unit tests which provide a safety-net against regression bugs.
So why don’t you give it a try?

Monday, May 12, 2014

Things I learnt reading C# specifications (2)

The story so far: After reading Jon Skeet’s excellent C# in Depth - again I’ve decide to try and actually read the C# language specification
You can read about in a previous post of mine:
Things I learnt reading C# specifications (#1)
And so as I continue to read the C# specifications along with the excellent comments by many industry leaders (I own the annotated version) and I keep discovering cool stuff about the language I’ve been using for more then a decade.
And so here is the second list of things I found out while reading the C# specifications:

args can never be null

Any .NET developer who ever created a console application knows what I’m talking about – there’s always a Main method with one of the four possible signatures:
  • static void Main()
  • static void Main(string[] args)
  • static int Main()
  • static int Main(string[] args)
Two of which pass the command line arguments (if any) used.
I’ve always was a bit defensive about the args maybe due to scars I have from writing C++ programs - although in C++ args would never be NULL but that’s a different story.
In any case according to the C# specs:
The string[] argument is never null, but may have length of zero if no command-line arguments were specified
So there you have it – one less thing to check for.

C# uses banker’s rounding

Every needed a value rounded in .NET – it might happen if you use the decimal type or explicitly using Math.Round. Ever wondered what would be the result of such round?
The fact is that usually it would behave as expected i.e. round to the closest number (integer) which means 0.9 becomes 1 while 4.2 becomes 4. But what happens when rounding half a number would it round or down?
The answer is “it depends” -  in fact both 42.5 and 41.5 would be rounded to 42!
This rounding happens mostly due to the fact that it’s the answer for the ultimate question but also because the rounding method used rounds to the closest even number. Known as the Banker’s rounding and it’s has many nice properties:
Over the course of many roundings performed, you will average out that all .5's end up rounding equally up and down. This gives better estimations of actual results if you are for instance, adding a bunch of rounded numbers. I would say that even though it isn't what some may expect, it's probably the more correct thing to do.
[From StackOverflow]

Boxing and “is” operator

All us .NET developers knows about Boxing & Unboxing, those of us who used the early 1.1 version used them extensively when using collections (we were young and needed the money and besides generics were not implemented yet).
Luckily these days I don’t use boxing/unboxing much but from time to time a value type (e.c. int) needs to be passed as a reference type and Boxing occurs.
But is it still a value type – of course not! it’s a reference wrapping a copy of the value we’ve been using so how come the following code would write “True”?
int myInt = 42;
object aBox = (object) myInt;

Console.WriteLine(aBox is int);

Why’s that? well, it’s part of the specs (4.3) and besides it’s the way I’ve subconsciously expected it to work in fact I’ve been using this behavior without noticing for years -  I had a int and so please don’t confuse me with Boxing because in my eyes it’s still an int.

That’s it for now, I’ll keep reading the specs and probably produce a few more posts on the way when I find interesting facts about the language I’ve been using for more then a decade.

Until then – happy coding…

Sunday, April 27, 2014

What to do when FakeItEasy throws System.BadImageException

Today I had a weird problem at work. I’ve been working with a new team and they’ve been writing unit tests using FakeItEasy when they got a strange error message:
System.BadImageFormatException: … The signature is incorrect.
Now I’ve been using FakeItEasy for some time and I never once saw this strange behavior.
Googling for the problem only showed a bunch of solved issues but no solution to my specific problem.
Since I needed to solve this problem – I took a closer look at the code in question - the test code looked something like this:
public void Test()
    var fakeDependency = A.Fake<IMyDependency>();

    var classUnderTest = new MyClass();

    A.CallTo(() => fakeDependency.SomeMethod()).MustHaveHappened();
The exception in question happened on the last line where we’ve used FakeItEasy to verify/assert that a method call occurred. Looking at the problematic interface didn’t help much:

public interface IMyDependency
    DataClass SomeMethod();
Until they tried changing SomeMethod’s return value to an object which caused the test to run properly.
This strange story made me think that perhaps the problem was the method’s return value (duh) and so I’ve asked in which assembly DataClass was declared. As it turned out it was in another assembly – not the one we were testing (the one with  MyClass inside).


And then we understood – since the test didn’t have a reference to AnotherAssembly.dll FakeItEasy had a little problem settting behavior on it or verifying method class on method that returns DataClass .

The fix was simple – add a reference to the assembly with DataClass.

If that machine had Resharper installed we would have found the problem quicker:


Sad but true, in any case once the reference thing was sorted out the test run smoothly.
Related Posts Plugin for WordPress, Blogger...