Wayne Allen's Weblog

Context Sensitive Config Files

M. Keith Warren was asking for an enhancement to the web.config to look like:

<configuration Name=”Release”>
    <system.web>
 …
    </system.web>
</configuration>
<configuration Name=”Debug”>
    <system.web>
 …
    </system.web>
</configuration>

We solved a similar problem for all config files by creating a wrapper around AppSetting and ConfigurationSettings that looked at various things (machine name, database server, ...) to determine the environment and use the correct settings. I.e.

<appSettings>
     <add key="logging-level" value="debug" />
</appSettings>

<test-environment>
     <add key="logging-level" value="verbose" />
</test-environment>

<prod-environment>
    <add key="logging-level" value="brief" />
</prod-environment>  

This demonstrates also the cascading feature, if the environment is not specified the setting in appSettings is used, this way common settings don't have to be repeated.

Is FIT Testing Useful?

A question came up yesterday as I was explaining the virtues of FIT to the development team (see my previous entry).

The question was “Is FIT testing actually valuable?” The argument being does FIT testing eliminate or reduce the need to do any other type of testing? I.e. would the addition of FIT tests decrease the need for GUI testing? The preliminary answer was maybe if the QA person believed the FIT test results. The main objection was that even if I use FIT to test the domain layer, I still need to test the interaction of the UI layer with the domain layer, thus testing the domain layer as a result. The addition of FIT just adds a maintenance burden to the QA team.

Based on that argument the only value FIT would add would be systems that do not have a UI, i.e. services.

Playing with FIT

Spend a few odd hours over the last week integrating the ability to run FIT tests into our wiki. Generally everthing worked well except I was having trouble figuring how to bring the wiki pages that described the tests together with the code that actually got tested with the framework that brings them together.

A little discussion with Ward led me to the light. Turns out I was trying to bring the code under test to the test definitions (wiki pages). What Ward suggested was to take the test definitions to where the code is located. So now I need to work with Draco.NET to ensure the FIT tests run every night.

Do You Model?

An interesting discussion with a co-worker today related to the release of Together.NET. We were discussing why we weren't really interested and realized that neither of us thought about code in UML. Rather we thought about code as components with services. Personally I used to think about code in UML, but about 3 years ago I just kind of stopped.

Interestingly I do think about databases in ER diagrams. I believe that the difference is that my ER diagrams directly map to the structure data in the database and the relationships between the tables. Whereas in UML I have to look at several diagrams to understand the behavior.

Therein lies the difference. My database diagrams are structure only, but my code is behavior with structure and really I don't need to see all the gory details about my code, just the high level i.e. components.

Do you model? Do you think in models? How does it advance your creation of working software?

Technical Debt

Martin Fowler wrote a post about technical debt that struck a nerve we me and others.

Our company as well as others I've worked for in the past and I suspect everyone else struggles with this every day. How does one help the business side of the house understand the implications of the quick fix? I don't know that this is a solvable problem because it requires predicting the future. Applying a quick fix to application A is the right solution if it so happens that it is retired before the accumulated debt becomes overwhelming.

So how do we measure technical debt? If we could the argument for time to rewrite vs. fix would be easy.

Vault NAnt Tasks

Brian Schkerke, Ryan Duffield, Robert Hurlbut and I put together a project to add Vault support to NAnt at http://vaulttasks.sscli.net/. Eric Sink was kind enough to provide a Vault server, but it dosen't allow public access. All the necessary commands necessary for integrating Vault into Draco are provided. Thanks to several of my developers for working on these tasks.

UPDATE: Eric Sink has made a guest account available for the Vault server at http://vaultpub.sourcegear.com. Get the Vault client install here: http://vaultpub.sourcegear.com/VaultService/downloads/VaultClient.msi. The repository is “Build_Tool_Integration”. Check it out.

UPDATE 2: On re-reading my post I realized that I made it sound like my team did most of the work, when in fact Brian Schkerke did the first implementation and we tweaked his code as well as adding one or two new tasks.