Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Testing - It's About Ensuring Correctness

Often times I get the sense that others think I'm a nut for testing.  There are plenty of others out there who are far more dogmatic about testing than I am.  In fact right now I'd be ashamed to share with you the test coverage of our current project.  I will say that the old codebase from which we are migrating had 0% coverage and I'm proud to say, confidently, that we're beating that number handily.

Testing, at it's very core, for me, is about ensuring correctness.  Whether you're testing using an automated testing framework such as NUnit, MbUnit, or xUnit or you test by hitting F5 and running your project, you're seeking correctness.  For the moment forget words such as "Unit Test", "Integration Test", or "System Test".  Those terms only indicate different scopes on which you can test for correctness.  Often they confuse more than they clarify.  They have their place, just not here right now.

I came across the following code the other day:

   1: public Address GetBillToAddress()
   2: {
   3:     return shippingAddress;
   4: }

See the problem?  Yeah, it was an easy one.  This code, as it sat, was not tested.  The problem with the code above is that it's so simple that it's easy to think it doesn't need to be tested.  Most users use the same billing address as their shipping address, thus masking the error for the vast majority of users.  The danger lies in a simple bug like this masquerading as something more insidious.  For example, this method is part of the "User" class in an eCommerce application.  The application verifies the users credit card by sending credit card information along with billing address to a credit card validation component.  We've already said that most users would have the same billing address as their shipping address.  However, imagine when a user comes by who has different shipping and billing addresses and now the user is being told that their credit card cannot be validated due to the billing address not matching the address on the file with the card.  I see a couple of scenarios happening but two that I want to address specifically:

  • In the worst scenario, the user will just go to a different site, knowing their credit card is good and assuming our site is wrong.  We lose the sale and are not alerted to the problem on the site.
  • The second, less likely scenario is that the user calls our customer service department to tell us the problem.  The customer service department verifies the problem and gets in touch with the manager of the eCommerce department.  The eCommerce manager verifies the problem as well and gets with one of the developers to find/fix the problem.  The developer then begins to research the problem and may find it immediately or may start looking in the wrong place, the credit card authorization component.

While I'm being a bit overly dramatic here, it's for good reason.  How hard,even if you know very little about testing or are new to automated testing, do you think it is to test the method above?  5 minutes? 10 minutes? An hour?  Compare any of those estimates for putting an automated test in place versus the money lost in the first scenario or the time spent in second scenario.

Too often people look at testing for only the non-trivial functions, for example their custom implementation of the Great-circle distance algorithm.  It's easy to discount testing the simple stuff.  However, a simple bug like this making it's way to production validates the point Steve McConnell makes in Code Complete; the later a bug is found the more it costs to fix it.

If you aren't testing your code, start.  Don't worry about whether or not you're doing it right or not if you're new to testing.  Any test is better than none, despite what many in the business will tell you.  I'd take 10 badly written "unit tests" (that zealots are quick to point out are really integration tests) rather than one well-written one.  Testing isn't an all or nothing proposition.  It's about ensuring correctness.  It's about continuous improvement, being better than you were yesterday.  Testing a bit more than you were yesterday.  Go on, take that first step, write a test or two.


Posted 09-30-2008 9:40 PM by Tim Barcz
Filed under:

[Advertisement]

Comments

DotNetKicks.com wrote Testing - It's About Ensuring Correctness
on 09-30-2008 10:42 PM

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Jak Charlton wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 2:54 AM

>>>Any test is better than none, despite what many in the business will tell you.  I'd take 10 badly written "unit tests" (that zealots are quick to point out are really integration tests) rather than one well-written one. <<<

I was with you until this point.

1 well written test has business value, 10 badly written tests further concrete a poor design, making your code more and more rigid over time - eliminating rigidity should be one of the core principles that drives your coding standards, adding tests should not.

Jak Charlton wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 3:03 AM

Here are the badly written tests for your code, I just made a manager smile by adding dozens of new, passing, unit tests ... I just made my other developers weep openly in the office at an appaling set of tests, all of which are valid by your criteria, and all of which pass.

Refactoring according to the "bug" you pointed out in this is now a case of rewriting 22 unit tests none of which added no value to the application, and even after rewriting will still add no value.

public Address GetBillToAddress()

{   return shippingAddress;  }

Address myAddress = new Address();

myAddress.ShippingAddress = "my address";

Assert.Equal(myAddress.ShippingAddress, myAddress.GetBillToAddress());

Assert.Equal(myAddress.GetBillToAddress(), myAddress.ShippingAddress);

Assert.Equal(myAddress.GetShippingAddress(), myAddress.GetBillToAddress());

Assert.Equal(myAddress.GetBillToAddress(), myAddress.GetShippingAddress());

Assert.Equal(myAddress.GetShippingAddress(), myAddress.BillToAddress);

Assert.Equal(myAddress.BillToAddress, myAddress.GetShippingAddress());

Assert.Equal(myAddress.ShippingAddress, myAddress.BillToAddress);

Assert.Equal(myAddress.BillToAddress, myAddress.ShippingAddress);

Assert.NotNull(myAddress.GetShippingAddress());

Assert.NotNull(myAddress.ShippingAddress);

Assert.NotNull(myAddress.GetBillToAddress());

Assert.NotNull(myAddress.BillToAddress);

Assert.True(myAddress.GetShippingAddress().Length>0);

Assert.True(myAddress.ShippingAddress.Length>0);

Assert.True(myAddress.GetBillToAddress().Length>0);

Assert.True(myAddress.BillToAddress.Length>0);

Assert.Equal("my address",myAddress.GetShippingAddress());

Assert.Equal("my address",myAddress.ShippingAddress);

Assert.Equal("my address",myAddress.GetBillToAddress());

Assert.Equal("my address",myAddress.BillToAddress);

Jak Charlton wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 3:11 AM

And ... because condensing this to one comment would have been messy ...

One of the primary functions of a test is to document intent. Probably a more important objective than to verify correctness.

A badly written test will concrete the bad design not only into the code base, but also into the intended usage patterns, and into the common language that is shared within the project and team - it will cause so much fall out across the project, that I would suggest that zero tests is better than a single poorly considered test. Udi got it spot on this morning, tests are not things which have TestFixture on them, they are well considered, well designed and have business value *in themselves*

Having been on a projkect which had nearly 6000 unit tests, which had been written poorly and to meet management expectations that numbers of tests would rise in line with progress (or vice versa), I can assure you it is not a position you want to be in. That codebase may have had some very valuable tests, but as 30% of them failed and were ignored every day as they were the result of refactoring or later changes, the whole lot had to be dumped to ensure that progress could continue without spending the whole development team's time on rewriting tests non stop.

Reflective Perspective - Chris Alcock » The Morning Brew #191 wrote Reflective Perspective - Chris Alcock &raquo; The Morning Brew #191
on 10-01-2008 3:31 AM

Pingback from  Reflective Perspective - Chris Alcock  &raquo; The Morning Brew #191

Ian Cooper wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 4:13 AM

@Casey

The trouble is that your argument becomes 'let's not do unit tests because they are too hard'  very quickly. It is great to teach people what the best practices are, but its hard to get folks to run better when they don't even know how to crawl.

Most of the people I know who now speak about best practices in unit testing learnt the hard way, by getting it wrong. A few folks got lucky and had someone on site to help them out who had that experience, but most of us did not. How did you start Casey? Did you learn by making mistakes? Or have your tests always been perfect, never needing refactoring.

It is arrogant to assume that people do not write good unit tests because they cannot grasp the value of those best practices. People do need though it is to practice in order to acquire new skills. You cannot learn the advanced techniques without learning the basics. Years ago when I used to do fencing at school I spent the first few lessons mastering footwork, without even holding a sword. In a fight a lack of a sword would be useless, but you had to master the basics first. The same is true of TDD, people need to master the basics.

For most of us that learning has always occured on the job. To deny that is to suggest that you have never written a system where you looked back and though I could have done better.

Indeed the purpose of the retrospective is to allow us to improve what we have just done.

I'm not ashamed to say that we have to go back and revisit our code in later iterations to clean up debt that we did not spot in the first iteration, because that is the common experience. As we write more tests, as we experiment with new techniques we learn more. When mocks came out we followed a lot of 'best practice' and mocked our dependencies. That caused us pain so we changed our practice. We don't know that beforehand, we had to learn it. And it was not the common wisdom of the day.

We need to spread the understanding that we all had to learn the basics and then improve. A lot of people give up because they think that the targets we set are beyond them.  They imagine that wisdom bursts forth full formed like Athena from Zeus's head. It does not. It comes with experience. They do not realise that we are able to give the advice we give today, because we learnt from experience.

I don't think that Tim is saying he wants bad unit tests in the pejorative sense that your comments allude to i.e. write the worst tests that you can. I think he means in the sense that it is better that folks begin the learning experience instead of giving up because the 'barrier to entry is too high'.

We are in danger of turning TDD into series 7 of Lost. So esoteric that no one who has not been with us from the beginning can start watching. We need to tell folks to start at Season 1 and work their way through.

Their advantage is that they can get to where we are a lot faster by learning from our answers to the problems they hit.

But the journey of a thousand miles always begins with the first step.

Jak Charlton wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 4:44 AM

@Ian

There is no business value to the tests I gave, and yet I have seen exactly those tests time and time again on codebases, where the managers proudly tell me they have a really tight ship. A small refactoring excercise becomes a nightmare in test maintenance.

If a developer doesn't know how to write a good test (not the same as how to use SOLID or how to test only a unit), then whatever they produce will be bad - and they really should not be putting it into the code base.

I started by writing unit tests, trying it, but *not* writing tests for the sake of it. I started by writing tests where the logic I was writing was too complex to verify by observation only.

In fact the first unit tests I wrote were against a calculation engine to measure and calculate yardage of rail tracks. One class and one class only in that project had unit tests, and they tested only what the requirements said they should verify as expected behaviour of test data in vs results out.

I could have written a few thousand tests against that codebase very easily, and very quickly, and given managers the impression these had value and that I was working hard - I would have been lying.

Bad tests are worse than no tests - this is not a debate about how to do TDD or POUT or what a "unit" is ... this is what happens if people who do not understand what a "test" is start writing "tests" in their tool of choice ...

Our current project has around 180 unit tests, it probably *should* have 2000+ but I'm the only developer on it confident enough writing unit tests to do them - for the others I'm not enforcing writing tests on them, I am enorcing writing good code in the first place that we can refactor easily afterwards, and evolve the tests around that when that code becomes more stable.

Casey Charlton - Insane World wrote Testing Is Not Technically Hard, It Is Hard Because It Requires Clear Thought and Understanding
on 10-01-2008 5:09 AM

This whole &quot; lets make TDD easier for the masses &quot; thing is getting out of hand . Unit tests

Ian Cooper wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 5:13 AM

@Casey

Why are you the only developer writing tests? Why are you the only one who has that confidence. The fact that you only have 180 out of a projected 2000 tests suggests that you have a big problem. That problem might be bigger than the problem of some tests that have no value.

I hear you on people just 'doing the numbers on testing' but again I don't think that is what Tim is saying.

Community Blogs wrote Testing Is Not Technically Hard, It Is Hard Because It Requires Clear Thought and Understanding
on 10-01-2008 5:29 AM

This whole &quot; lets make TDD easier for the masses &quot; thing is getting out of hand . Unit tests

Jak Charlton wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 5:40 AM

Tim's approach leads to the tests I gave above - because the developer doesn't know where to stop, or what tests are adding value and which aren't, or which are causing rigidity, and which are testing implementation not behaviour.

I'm the one writing tests as we are testing the core, business value is derived by delivery, not by training developers on this project. Technical debt is acceptable.

Ian Cooper wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 7:37 AM

@Casey I honestly don't think that Tim is proposing the tests that you outline in your example.

I think he is proposing not worrying too much about Micheal Feathers rules of good unit tests i.e. he may have integration tests etc.

I think you are taking a specific issue that you have and assuming that Tim is proposing that. Which he is not.

Without tests btw you cannot refactor the rest of your code base. Refactoring always implies tests to preserve behavior, even bad tests. You can change your code, but without tests your risk is unbounded.

Tim Barcz wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 7:55 AM

@Casey and @Ian,

A lot can happen when the American is sleeping.

Casey, I believe that Ian has represented my position well (thanks Ian).  I'm not suggesting writing tests to meet some managers approval or some magical number of tests.  The idea is that to become a master at something, very often you have to first be a beginner.  If the fear of doing it wrong paralyzes you to never start you never can become a master.

The goal, again thank you Ian for your thoughts, is to start.  In the last few sentences I talk about how it's being better today than yesterday, continuous improvement.

I simply want to encourage those who are fearful of writing unit tests (because they fear they'll get them wrong) to start writing unit tests.  I wrote a lot of what I would consider bad tests now when I first started.  They did add value though.

You've got to start somewhere or not start at all, I propose starting somewhere.

Jak Charlton wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 8:19 AM

I propose learning first ... on that point we differ - I don't want anyone learning in a production code base ... they can learn on their own time, in training sessions, on spike code, or anywhere else, except production code.

Anyone left unguided will write the example unit tests I gave you based on your example ... I didn't need to use SRP or any other principle to screw that up ... how do you propose stopping people writing those tests?

Add a tool that means you don't even have to write good code to add a bad test on top and you will end up with shockingly bad codebases - managers will still only look at numbers like # of tests and coverage % - so your job is safe though.

Tim Barcz wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 9:17 AM

@Casey,

Often we hear about the 5:01 developer.  Where else are they going to learn if not on a production codebase?  You mentioned earlier that you're the only one writing unit tests.  You are reviewing code it sounds like, why not review the unit tests and use this as a teachable moment?

I don't think it's fair for people to sit back and exclaim that people should be testing and then when they do start testing rail them for writing "bad" tests.

Casey wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 10:24 AM

@Tim

>>>Often we hear about the 5:01 developer.  Where else are they going to learn if not on a production codebase?<<<

train them, or fire them - simple solution. Don't let them start learning on production code, or make sure you only ever work in pairs.

Dew Drop – October 1, 2008 | Alvin Ashcraft's Morning Dew wrote Dew Drop &ndash; October 1, 2008 | Alvin Ashcraft's Morning Dew
on 10-01-2008 10:27 AM

Pingback from  Dew Drop &ndash; October 1, 2008 | Alvin Ashcraft's Morning Dew

Tim Barcz wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 10:43 AM

@Casey

Fire them?  That's your advice?!?  Come on Casey...

I'm all for training but why not on production?  It's the only way to learn in a non-trivial environment.

Kind of like NFL quarterbacks...they may be great in practice but they need experience and game-time to really mature.

Jak Charlton wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 1:22 PM

>>>Kind of like NFL quarterbacks...they may be great in practice but they need experience and game-time to really mature.<<<

But they didn't get to the NFL without playing at high school, then at university, then in the reserves ...  

Tim Barcz wrote re: Testing - It's About Ensuring Correctness
on 10-01-2008 1:37 PM

>>>But they didn't get to the NFL without playing at high school, then at university, then in the reserves ...  

Further proving my point...they are always playing in the highest level possible for their time (their "production code" if you will).

2008 October 02 - Links for today « My (almost) Daily Links wrote 2008 October 02 - Links for today &laquo; My (almost) Daily Links
on 10-02-2008 4:00 AM

Pingback from  2008 October 02 - Links for today &laquo; My (almost) Daily Links

mwatts wrote re: Testing - It's About Ensuring Correctness
on 10-02-2008 4:25 AM

I think I'll have to agree with Casey on this one. On the original subject I mean, not on the whole "where to learn" issue.

The problem with having developers just start writing tests out of nothing, tests that will not add real value, is that they will not see the advantages the tests could have had.

A test has advantages when it either saves time and / or prevents bugs in production.

If a developers experience with tests is that they only slow him down (writing and maintaining the test) and that the test has never given him any tangible benefit, he will not, at least not by himself, start designing with testability in mind, or start writing tests again, the next project he is on.

Now that's a long sentence. Sorry about that. ;)

Anyway, I doubt the intended goal, which is getting the develop into TDD, will be achieved if his first experience with it is negative, because of poor guidance or the lack of a clear goal and vision.

Arjan`s World » LINKBLOG for October 2, 2008 wrote Arjan`s World &raquo; LINKBLOG for October 2, 2008
on 10-02-2008 11:29 AM

Pingback from  Arjan`s World    &raquo; LINKBLOG for October 2, 2008

Ian Cooper [MVP] wrote Learning On A Project
on 10-10-2008 4:30 AM

There has been a fair amount of activity in the blogsphere to Roy&#39;s original post about increasing

Community Blogs wrote Learning On A Project
on 10-10-2008 4:56 AM

There has been a fair amount of activity in the blogsphere to Roy&#39;s original post about increasing

Mirrored Blogs wrote Learning On A Project
on 10-10-2008 5:31 AM

There has been a fair amount of activity in the blogsphere to Roy&#39;s original post about increasing

Buspar. wrote Buspar depression.
on 11-18-2008 12:06 AM

Buspar online med.

social bookmarking sites submission wrote re: Testing - It's About Ensuring Correctness
on 01-18-2013 5:36 PM

63PZCA I think this is a real great article.Thanks Again. Fantastic.

clomid no prescription wrote re: Testing - It's About Ensuring Correctness
on 02-24-2013 9:09 PM

gLKbUY Enjoyed every bit of your blog article.Much thanks again. Awesome.

clomiphene 25 mg wrote re: Testing - It's About Ensuring Correctness
on 02-28-2013 11:27 AM

F9P7OD Really appreciate you sharing this article post.Really thank you!

http://1buyviagrahere.com/ wrote re: Testing - It's About Ensuring Correctness
on 03-03-2013 6:56 PM

Z5yDIr Very informative blog post.Really looking forward to read more. Keep writing.

bookmarks wrote re: Testing - It's About Ensuring Correctness
on 03-13-2013 3:22 PM

dwfFPu Very informative article post.Really looking forward to read more. Fantastic.

social bookmarking service wrote re: Testing - It's About Ensuring Correctness
on 03-24-2013 9:54 AM

dOPPyf I loved your article post.Really thank you! Fantastic.

social bookmarking service wrote re: Testing - It's About Ensuring Correctness
on 04-04-2013 1:19 AM

FsgX1A Looking forward to reading more. Great article post.Thanks Again. Awesome.

Social bookmarks wrote re: Testing - It's About Ensuring Correctness
on 04-12-2013 9:01 PM

gNEEKk I truly appreciate this blog. Great.

buy social bookmarks wrote re: Testing - It's About Ensuring Correctness
on 04-20-2013 7:30 AM

XuZIzY Very neat article. Want more.

link building team wrote re: Testing - It's About Ensuring Correctness
on 09-30-2013 11:41 PM

vKAg7O This is one awesome blog post.Really thank you! Cool.

qnrqyg@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 07-29-2014 8:02 AM

reasonably priced comprehensive jerseys experiencing burning in shooting against glendale suit clipping-borders

logmpcr@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 07-30-2014 12:51 AM

Buy online For affordable what exactly are these people in search of

zutpnm@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 08-11-2014 5:26 PM

Inexpensive National football league Items On the net regular sharks target this past year because fly

jkkfvmr@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 08-12-2014 11:37 AM

Affordable Authentic Nike American footbal Cycling tops Free freight the newest approach faucets just about every tutor ohydrates stand out point regardless of whether that's mathematics

spdbfl@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 08-26-2014 9:55 AM

Tiffany And Co Cheap Rings bristol had no qualms or inhibitions with shaking her hips.

Tiffany Co Jewelry www.slvrenewalhouse.org

pwpjkysnol@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 09-01-2014 4:42 AM

Online Jewelry Business sewn into the left hand upper seam of the left hand pocket.

sieimslriwz@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 09-19-2014 6:57 AM

Where Can I Buy Cheap Shoes Online phil made some plays in crucial moments and played very well after the first four minutes.

jlhlvxhr@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 09-23-2014 3:59 AM

Ugg Women Boots Sale the Nets are looking to cut costs and Pierce saw the opportunity to escape.

kfifzbxmizg@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 10-06-2014 4:29 PM

Allen Edmonds Outlet Sale irrespective of how good or bad you are as a photographer.

mvzoywdsg@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 10-08-2014 5:08 AM

Ugg Outlet In Orlando and for the bold texture and dark green of their summer leaves.

kfxkinxqlg@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 10-30-2014 10:48 AM

Ugg Boots For Cheap for example rent their furniture and tvs for over.

Cheap Uggs On Sale http://www.fern-studio.com/

uwgeibhq@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 10-31-2014 10:27 AM

Ugg Orlando Outlet they all freestyled and I discovered I could beat box.

fybbcncav@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 10-31-2014 1:26 PM

Mulberry Backpack bloomin' numbers.

qftace@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 11-08-2014 11:05 AM

Ugg Men Sale i read the New York Ugg Men Sale Times best seller on public court records recently.

fttmeeaduig@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 11-09-2014 10:19 AM

Cheap Uggs Boots never leave a child unsupervised with a puppy or dog.

ffqorrwc@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 11-15-2014 7:11 AM

Mulberry Outlet Bicester mulberry bags outlet we usually do not.

ayonsntcx@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 11-15-2014 2:33 PM

Where To Get Ray Bans For Cheap oakley sunglasses cheap free shipping on saturday surpassed the site s previous record holder.

awsacu@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 11-21-2014 10:38 AM

ugg black friday sale by heaneyl 71 followers

abuegpmoz@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 11-21-2014 2:05 PM

Cheap Ray Ban Glasses Frames how to make fake ray bans the dart shaped boats have broad.

haycakuwzql@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 11-22-2014 11:06 AM

cyber monday ugg boots rather than the worn out phrase

camyviaao@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 11-23-2014 6:47 AM

Pink Mulberry Purse mulberry bags sale 24 mulberry st.

byyughrzb@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 12-08-2014 6:57 PM

Mulberry Backpack mulberry outlet but shadows are rarely literal.

yunnfwk@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 12-09-2014 1:44 PM

Cheap Black Ugg Boots piano black finish and only two subtle LED indicators on the front.

sgfgsg@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 12-17-2014 1:59 PM

Ugg Bailey Sale the entire defense related budget will total up to.

bjcwfca@gmail.com wrote re: Testing - It's About Ensuring Correctness
on 12-20-2014 3:32 PM

Ugg Outlet Boots there are many kinds of boots we may find Ugg Outlet Boots in the market.

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)