Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,131 | Comments: 45,568

filter by tags archive

Defensive coding is your friend

time to read 1 min | 177 words

We just had a failing test:


As you can see we assumed that fiddler is running, when it isn’t. Here is the bug:


Now, this is great when I am testing things out, and want to check what is going on the wire using Fiddler, but I always have to remember to revert this change, otherwise we will have a failing test and a failing build.

That isn’t very friction free, so I added the following:


Now the code is smart enough to not fail the test if we didn’t do things right.


Frank Quednau

As with every good advice, there is the evil counterpart: paranoid coding, when you litter your code with excessive null checks on things that cannot be null, catch exceptions you cannot handle, etc.


I wouldn't call this defensive coding. You created testable code WAY different.

Defensive coding IMHO is ONLY EVIL... But we migh mean different things,. To me defensive coding is what Frank is describing as paranoid coding :)



I did a similar thing recently where I was testing seeding the database. This meant destroying and rebuilding it from NHibernate. However the config file was pointing to the QA database so it got wiped and needed to be restored from backup. Now I have an assertion in TestInitialize that ensures the database is local before seeding it with test data.

Serhiy Kalinets

bool args do not add clarity to the code. When you catch GetServerUrl(true) in the code it may be tricky to figure out what that true means without looking at method signature.

Daniel Lang

@Serhiy, this is why you can and should use named parameters in these cases, like GetServerUrl(fiddler:true)



Now the code is smart enough to not fail the test if we didn’t do things right.

Is that really a good thing? It doesn't sound it.

Feels like the sort of thing which could lead to false positives, thinking you were actually testing something when internally it was circumventing it.

Daniel Wonisch

Still this seems to me as a nasty workaround instead of a real solution, what might be OK for test code but wouldn't be acceptable in production code.

@Daniel: I have to be on Serhiy side of view. Since you do not want the developer to enable or disable fiddler all the time, but let the system take the decision for you, a better signature for that method would be GetFiddlerUrlOrDefault().


Ayende, is that you?....


Just wondering...Ayende writing fragile tests? This is not best practice.

Comment preview

Comments have been closed on this topic.


  1. RavenDB Conference 2016–Slides - 5 hours from now
  2. Proposed solution to the low level interview question - about one day from now

There are posts all the way to Jun 02, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats