Derik Whittaker



Testing only the code of value

I am 99% sure I have had a post like this in the past, but my google-foo was weak today and I could not find it.  Do not let anyone blow smoke up your back side, testing is expensive, testing takes time but most importantly testing can help improve the quality of your code.

If you are going to spend the time and money to create automated, rerun-able unit tests make sure you spend your time/money wisely.  Make sure you test the code that matters, test the code which is complicated (keep in mind a LOC count does NOT equal complexity).

Today when scanning some code in another part of our project I came across this tests:

public void AdminSetIDTest()
	var target = new CreateTaskActivity();
	int expected = 50;
	int actual;
	target.AdminSetID = expected;
	actual = target.AdminSetID;
	Assert.AreEqual(expected, actual);

When I looked at this tests 2 bells immediately went off in my mind

  1. The name of this tests SUCKS BALLS and does not clearly convey the intent of the test
  2. This is testing that a property getter works (no, there is NO logic behind the getter/setter)


If you disregard #1 from above for now (but remember clear/concise names do matter) and focus on #2 this tests adds no value to the test suite.  All this test is doing is ensuring that the .Net framework does its job.  This test is a total waste of time and energy and can actually cost you more time/money in the long run because you may have to change the useless test over time as you refactor.

The key take away from this is simple.  You always have limited time and money when trying to get a product out the door.  Unit testing IMO can always help you to create a better product, but make sure you use your time and money in a way in which will allow you to maximize your ROI.

Till next time,

Posted 10-07-2009 6:48 AM by Derik Whittaker
Filed under: , ,



Thomas Weller wrote re: Testing only the code of value
on 10-07-2009 8:10 AM

Obviously, the above test doesn't look very spectacular. It verifies seemingly 'only' the correct working of a property getter/setter.

But whether it's useless or not, depends on what is behind the property setter. There may be some sophisticated validation logic or whatever. The point is: You can't see that from the test, and there might be value in having such a test in certain situations.

And you will also have such a test if you're following a strict TDD approach.

- Thomas

Derik Whittaker wrote re: Testing only the code of value
on 10-07-2009 8:31 AM


RE Logic behind the getter/setter.  In the post there is a note that there is NO logic behind the getter/setter.  In fact checking this fact was the first thing i did. wrote re: Testing only the code of value
on 10-07-2009 10:46 AM

You laugh at this test being useless and a waste of time. I must agree given the condition you work with competent developers.

At a company I once worked for I wrote some generated tests that did just what you showed above for the entire data layer. I found a half dozen bugs and/or really bad decisions. In one example setting prop A had no effect, and setting prop B changed the value of A. In another a simple copy/paste error caused setting prop A to change the value of B.

So I must contest that these simple tests are not useless. The are however a waste of time, it's trivial to generate the test code. One benefit to generating tests like this is that new properties are covered and old ones removed with little to no work.

Paco wrote re: Testing only the code of value
on 10-07-2009 10:51 AM

When you write your code TDD, test first code later, you will write those tests. I don't see value in removing those tests.

Personally, I try to use not much setters at all.

I don't create tests for dumb DTO's with autoproperties only (like viewmodels) but I do test everything else.

Derik Whittaker wrote re: Testing only the code of value
on 10-07-2009 11:01 AM


Even w/ TDD i would not see myself ever writing a test in this manor.

Bob Saggett wrote re: Testing only the code of value
on 10-07-2009 11:53 AM

Don't see the problem with testing getters and setters. Set up a template so the test takes two seconds to add. If anyone ever modifies the logic behind the property you can determine if it breaks anything for very little cost.

If you are hand-coding this crap then you have a problem and need to learn how to use your tools properly.

jdn wrote re: Testing only the code of value
on 10-07-2009 11:55 AM

I agree that with TDD done strictly, you might end up with tests like this.

Which is all the more reason not to do TDD, and do Specification-style BDD.

Pedro wrote re: Testing only the code of value
on 10-07-2009 6:05 PM

This reminds me of a project I worked on a couple years ago.  The database and associated data objects had evolved over time, but not everything had been cleaned up.  We had unit tests to validate business logic, but fortunately none to specifically test the getters and setters.  Because of this, a quick look over the code coverage info showed us a number of properties that were no longer being used - which we happily deleted.  Property unit tests would have masked this info.

Franklin Webber wrote re: Testing only the code of value
on 10-07-2009 6:54 PM

I see no harm with having test for getter/setter calls.  I'd say that this is only a sin if the developer stated that tests were written and I came across these.

Dave Schinkel wrote re: Testing only the code of value
on 10-07-2009 11:59 PM

I'm going with testing methods, not properties..that's my approach.  Makes no sense to waste time testing properties.  Your properties should not have a lot of logic in them anyway, that's what methods are for.

Steve Gilham wrote re: Testing only the code of value
on 10-09-2009 2:46 AM

If your properties are really just public field accesses dusted with syntactic sugar, automated static analysis can do the job of verification, including matching property and backing field names as desired.  Running this sort of analysis in conjunction with coverage assessment avoids having lots of trivial tests and will distinguish well-formed properties that are actually not used from ones that are.

Sanjeev Agarwal wrote Daily tech links for .net and related technologies - October 9-11, 2009
on 10-10-2009 4:16 AM

Daily tech links for .net and related technologies - October 9-11, 2009 Web Development Using MvcContrib

X.509 wrote re: Testing only the code of value
on 10-20-2009 6:46 PM

Derik, it is good that you teach people not to do UT of properties. And I completely agree with you regarding this. But World is not so simple. Here is a fairytale:

There was some project. There were times when there were no UT there at all.

And one day Big Boss decided to do Unit Tests after reading some nice article. So he set up a goal for the team- i.e. 1000 UT for next month.

It appeared that there were couple of "not very successful" builds before. So the lower level manager decided to encourage team to meet the goal and make Boss happy. He decided to pay developers for every UT and award one who will create max count of UTs.  

BTW as usual for some reason the scope of tasks was changed few times during that month and somebody had forgotten to change the delivery date after that.

Finally team created incredible count of UTs, lower level manager was able to report tha UT count is not zero any more, developer was awarded, boss was happy  - everyone was happy.

Moral: Everything has "back side of the medal". Take context into account...

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)