As I mentioned last week, I am new to TDD.  For better or worse, all of my tests (and spikes) have been generated via Visual Studio Test Projects.  Working with VS Test Projects hasn’t been all that bad although I noticed a couple of annoyances right away. 

Is anyone else bothered by the fact that, by default, an unlimited number of test results and binaries are "deployed?"  If you are testing first, this arguably makes for a lot of useless activity and waste disk space.  Since the default TestResults folder location is set to be side-by-side with your solution files, the extra folders, trx files and binaries can also really interfere with your otherwise easy source control check-ins. 

Fortunately, there are ways to work around the excessive TestResults problem if you are running VS2008.  Some options are available through the IDE and other require an update to the .testrunconfig file directly:

Limit the number of deployed tests:

Tools > Options > Test Tools > Test Execution > Test Results Management > Limit number of old Test Results to the value of your choosing. 

The screen shot below sets the number of tests to one.  Therefore all previous tests are purged and only the latest test is maintained.

Disable Test Result deployment:

If you wish to disable the Test Result generation completely, double-click on your solution’s .testrunconfig file and uncheck the "Enable deployment" option.  No results will be generated thereafter.

Change the Test Result folder location:

This option is hidden.  I don’t believe it is exposed in any of the VS 2008 dialogues and you have to edit the .testrunconfig file directly. 

Right-click on the .testrunconfig file > Open With… > XML Editor > Include the following within the TestRunConfiguration node:

<Deployment useDefaultDeploymentRoot="false" userDeploymentRoot="C:\TestResults" />

I hope it helps.

References:

• http://arcware.net/archive/2007/12/09/Limit-the-Number-of-Old-Test-Results-with-VS2008.aspx
• http://blogs.msdn.com/nnaderi/archive/2007/05/11/new-unit-testing-features-in-orcas-part-1.aspx
• http://weblogs.asp.net/stephenwalther/archive/2008/03/19/tdd-test-driven-development-with-visual-studio-2008-unit-tests.aspx
• http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3026907&SiteID=1

It is easy to see the subtle difference between the Product Tables below.  The table to the left adds the table name as a prefix to nearly all of the column names. The table on the right represents very simple column names with no redundancy.  Early in my career, I preferred the implementation to the right as I felt this pattern best represented the object (table) itself.  After all, we all have a name.  We don’t have a PersonName. Well, it didn’t take me long to change my opinion.

The next time you are designing a database, do yourself a favor and mimic the pattern to the left.  Always prefix column names with the table name if the column name is likely to be repeated  in more than one table.  ID, Name, Description, DateAdd and DateChange are good examples of column names which tend to show up in multiple places.  When it comes time to build your queries and work with the result sets, you will thank me. 

Consider the two following routines — each returns the same result but the latter is much cleaner, readable, consists of less code and is inherently greater resistant to stupid coding errors especially within the syntax of the join and the column aliases.

– Poor implementation
declare @Product table
(
    ID int, Name varchar(50)
)

declare @ProductVersion table
(
    ID int, ProductID int, VersionNumber int
)

insert into @Product(ID, Name)
select 1, ‘product 1′
union
select 2, ‘product 2′

insert into @ProductVersion (ID, ProductID, VersionNumber)
select 1, 1, 1
union
select 1, 2, 1

– Note the column aliases and
– join on less-than-obvious columns
select P.ID as ProductID, PV.ID as ProductVersionID from
@Product P inner join
@ProductVersion PV on (P.ID = PV.ProductID)

go

– Proper implementation
declare @Product table
(
    ProductID int, Name varchar(50)
)

declare @ProductVersion table
(
    ProductVersionID int, ProductID int, VersionNumber int
)

insert into @Product(ProductID, Name)
select 1, ‘product 1′
union
select 2, ‘product 2′

insert into @ProductVersion (ProductVersionID, ProductID, VersionNumber)
select 1, 1, 1
union
select 1, 2, 1

– Note there’s no need for aliases and
– the join obvious
select P.ProductID, PV.ProductVersionID from
@Product P inner join
@ProductVersion PV on (P.ProductID = PV.ProductID)

Keep this tip in mind.  It will save you heartache throughout your next project.

If I were to guess, I receive 2.25 bookstore gift cards and 1.25 books around Christmas each year. Nearly 100% of the tangible books have been non-technical in nature.  This year’s book — Beer School: Bottling Success at the Brooklyn Brewery — was a present from my soon-to-be sister-in-law. 

As I don’t tend to read much these days, it is taking a while to get through this particular gift, but I would already recommend it. It is a nice combination of beer history, entrepreneurial stories/advice and business/people stuff as told by the Brooklyn Brewery founders, Steve Hindy and Tom Potter, a journalist and banker, respectively, in a surprisingly light and down to earth manner.  Note: If you want to learn how to brew your own beer, you will need to turn somewhere else as this book probably isn’t for you. 

While sharing life and business lessons learned while building a successful brewery in NYC, Tom dedicates an entire chapter to the creation of the business plan where he goes as far as to write: “To the extent possible, avoid the word conservative.”  His rationale is clear and to the point:

When a business plan says that it ‘conservatively’ estimates this or sales will ‘conservatively’ reach that, most readers get a suspicious twitch.  When using the word conservative, you’re trying to feed the reader a conclusion and shortcut the private analysis.  It doesn’t work.  Readers will come to their own conclusions, wherever you try to lead them.  The reader is thinking: Don’t tell me that’s a ‘conservative’ estimate; just give me the facts, and I’ll tell you.

It is a very interesting view and, based on my experience with project estimation, I may start taking Tom’s advice to heart.  I mean, how many times have you provided a detailed work breakdown structure with accompanying dev hours just to have a project manager or someone with “authority” change your numbers solely based on their interpretation of the required effort?  This type of thing happens a lot — especially when you include a word like conservative along with your estimate.  In my experience stating an estimate is conservative is a green light for someone else to rework your numbers any way they wish. 

I know I am taking the original tip a bit out of context, but I think it still applies.  Though we tend to have opinions on everything, we might be better off just providing the facts while trusting the recipient will do with our numbers as they deem most fit. I, for one, know most of the folks which receive my estimates are intelligent individuals and they can certainly come to their own conclusions and agree or disagree with whatever I might provide. 

So, when I produce my next estimate, I’m going to present my numbers and the supporting facts and I’m going to keep my opinions to myself.  Well, at least until my estimate is challenged and I am stuck doing twice as much development in half as much time and then all Hell is going to break loose.  :)

Whenever I can get away with it, I include basic troubleshooting information in the footer of my web applications.  So it isn’t distracting (or blatantly exposed) to the standard user, the text is hidden.  In other words, I make the font color the same as the background color so the text is only visible when selected. 

The hidden text is intended to give the developer basic information about the logged-in user, server and build as well as enough information to link the user’s session back to more detailed logs. 

So, prior to a release to the Test Environment, I share the location of the hidden text with the QA and UAT groups and request they include the information when writing up defects.  And once the application rolls to the Production Environment, the Help Desk and Stability Groups begin to leverage the information as well. 

Even though the information is “hidden,” I am very particular/careful when it comes to the troubleshooting information which I present.  As a general rule, I only include information which would be harmless if “found” by anyone — including future auditors.  I use this technique with caution, but I do use it whenever I can.  I’ve found this “trick” very handy over the years and maybe now you will too.

Do you have any troubleshooting tips which can be shared?