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,124 | Comments: 45,471

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 3.5 whirl wind tour: You want all the data, you can’t handle all the data - about one day from now
  2. The design of RavenDB 4.0: Making Lucene reliable - 3 days from now
  3. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - 4 days from now
  4. The design of RavenDB 4.0: Physically segregating collections - 5 days from now
  5. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 6 days from now

And 14 more posts are pending...

There are posts all the way to May 30, 2016


  1. RavenDB 3.5 whirl wind tour (14):
    29 Apr 2016 - A large cluster goes into a bar and order N^2 drinks
  2. The design of RavenDB 4.0 (13):
    28 Apr 2016 - The implications of the blittable format
  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