Shawn has an interesting post where he talks about why 100% unit test coverage should be one of your goals. I agree 100%. I’m not sure why anyone would say that you shouldn’t be testing your properties. Don’t you want to make sure they work?

The prevailing philosophy in regards to unit testing is writing your tests before your code. In practice, this happens a lot less than it should. Why should we write our unit tests first?

• Writing your unit tests first makes you design pieces of your software from the clients perspective. After all, you’re writing your code to be consumed. The code itself is not important, it’s what it does for other code.
• Unit tests are meant to test functionality, NOT code! That means if you write your unit tests after the fact, you’re probably not focusing on the functionality. You might be trying to come up with edge cases that might not even matter to the client. It’s harder to come up with good unit tests after the code is written, because you’re not necessarily looking at it from the clients perspective, or from the perspective of the required functionality.

There are two valid ways to increase code coverage:

• Write additional tests - This only makes sense if you forgot to write the test initially. Since you’re tests are verifying functionality, why don’t you already have a test for this particular piece of functionality?
• Remove the untested code - In a perfect world, this is what you would always do. After all, your tests verify that your code has a certain set of functionality. If you have untested code, that code isn’t needed. Why keep code you don’t need?

Here is the basic process I recommend:

1. Come up with a rough design in your head
2. Write unit tests to test a required piece of functionality
3. Write the code to provide that functionality
4. Verify that the unit tests pass, fix the code as necessary
5. Refactor as necessary
6. Run a code coverage tool, and get as close to 100% as possible using one of the methods I mentioned previously.
7. Go to #2 and repeat as necessary

In my master page, I have a ContentPlaceHolder defined:

<asp:ContentPlaceHolder runat="server" ID="AfterScripts">
</asp:ContentPlaceHolder>

In the page, I have the content defined:

<asp:Content runat="server" ID="conTrackingScripts" ContentPlaceHolderID="AfterScripts">
    <!-- Blah -->
</asp:Content>

Unfortunately, this code does not work:

conTrackingScripts.Visible = false;

The error given is "The name ‘conTrackingScripts’ does not exist in the current context. A quick Google search shows that many others have had the same issue. The solution is to use the following code instead:

(Master as MasterPage).FindControl("AfterScripts").Visible = false;

Substitute the name of your master page for "MasterPage", and the name of your ContentPlaceHolder for "AfterScripts" in the above code

It appears that you cannot edit properties on the content, you have to edit the ContentPlaceHolder directly.

I received this question from ObiShawn:

"Does .NET/IIS output caching vary by user-agent?"

Good question Shawn! By default, the output cache stores the same version of the page for all users, regardless of their user agent. To change this behavior, add the VaryByHeader parameter to your OutputCache declaration:

<%@ OutputCache Duration="60" VaryByParam="*" VaryByHeader="User-Agent"  %>

This is probably a good idea to include in your OutputCache directive, because ASP.NET will render controls differently to some browsers. It modify the output HTML based on the browsers capabilities.

If your site is only targeting the latest generation of browser, you can probably avoid varying by user agent.

One last note. You can include multiple headers in the VaryByHeader parameter. Simply separate them with semi-colons.

For more information about OutputCaching, this is a great article.

I converted my Ubuntu home server to a Windows 2008 Server. The biggest challenge of the conversion was the 400GB RAID 1 array, which was Linux software RAID based. I threw caution to the wind, and figured that I could convert it after installing Windows Server 2008.

I was sort of banking on the fact that I could use the Ext2 installable file system for Windows to read one of the drives in the array. For some reason, it was unable to read the disk. I had assumed that since the drives were simply mirrors of each other, it would be able to read one by itself. I was wrong.

My solution was to create an Ubuntu Desktop virtual machine, and use it to mount the physical partition. I was then able to copy the files over the virtual network adapter.

In my last post, I talked about how your boss might have no choice but to judge your performance simply by the number of hours you work. Now I’m going to talk about some ways to change that.

If you’re boss is gauging your performance based on the amount of time your butt is in your chair, you have a BIG problem. He obviously doesn’t have a good understanding of what it is that you do. Obviously the short term solution is to figure out how to keep your butt in the chair longer for appearances. For example, come in earlier and catch up on the latest tech news. You may have been doing this at home, but why not get credit for it? The extra time you put in is also great for “playing” with the tools you use. It’s a good time to find out the most efficient ways to use them, so that you don’t have to get out of the zone when you’re working on something important.

Of course the long term solution is to change your bosses perception. Here are a few ways to do this:

• Let your boss share your pain. When you are running into hard problems, make sure he is aware of it. It might seem a little cruel, but if you don’t do it, he might not understand why you spent a week on something and have nothing to show for it.
• If you’re excited about something, tell your boss about it. He might just get excited about it too.
• In small talk situations with your boss, that’s a good time to give an update, but keep it short.
• In software development, there are changes that the average person would think are very easy. Your boss needs to be aware of when situations like that arise.
• Email weekly status reports to the tem. If you’re busy, this can be a good place to put some of the above suggestions instead of talking face to face. Your boss will appreciate your enthusiasm, especially if this is something that is not normally expected of you. It also serves as a good project history for him, yourself, and the rest of the team.

Also understand that your boss may need to report your progress to his boss. Be mindful of that, and try to boil down some of the information so that it can simply be repeated instead of being interpreted. Remember that anyone in the chain of command up to the President are interested in what you’re working on. The higher up you go, the more summarized the information needs to be. If you have opportunities to speak with them, you always want to be seen as passionate and motivated. It could very well affect a decision that they’ll have to make one day.