Bugs Bugs Bugs == More Unit Tests

I love writing code. I always wonder if writers feel this way .  I am sitting here working on the next minor rev (~June2005) and also the next major rev (~October2005 [ tied to whidbey release] ) with a CTP due out around the same time as the minor rev.  I am not going to go into why I can’t say 1.1 or 2.0 [oh wait I just said it ]. 

If you don’t know the source to Enterprise Library all that well, you might find this a little hard to follow, but hopefully you will get the point.

I got a bug on the RegistryStorageProvider not firing events when the data changes externally.  So what did I do, I wrote a test.  Heck it worked.  OK, mark as not repro, close bug onto next task in the iteration (another bug).  Uh-oh…. the tester [Gokula] turns to me smiling and says “it is still not working” (you do have your testers in the same room don’t you). Crap (not really what I said..)!  I know that this works, must be something wrong with the provider… write another test.  This test is easy, write the data then hook up the event handler, then open the key externally and muck with it.  Yeah I said it was easy, but it turns out that it took me a while to get there.   Hmmm test fails.  OK, write another test…. you get the idea. OK, this sucks.  I know there are those of you out there that might be going, why not fire up the debugger and start stepin’. Well, I guess I figure my tests tell me more about my assumptions than stepping through code that I already wrote

OK, I am going to cheat a little here because I am dealing with a couple of threads… good ol’ printf er.. I mean Debug.WriteLine(“Change handler created”);.  OK, never see the line. Ahhhh it is not the provider / change watcher that is broken (heck that code never runs), so must be higher up the stack.  After a few more tests, found it.  If you call Write before Read in the ConfigurationBuilder, the Watcher is never hooked up… oh I feel a green bar coming on.  Change the code, run the test, green light.  Run the suite of tests… all green.. check-in, close bug, go home, hope it doesn’t come back when I turn the lights off.

Now playing: Pink Floyd - One of My Turns

Comments (2)

  1. aaron m says:

    I’m going through the exact type situation this morning. Just came back from meeting with testers, they can produce bug, but I couldn’t (mostly within the UI) .. I need to add more tests. Thanks for the post Scott 🙂

  2. Sam Dahan says:


    first let me give you and all the guys at EntLib a big kudo – that is awesome work! Even if I don’t use all the blocks or all the function, just looking at your code is an edification in itself (so that’s how the gods do it…).

    I really, really like the feature that we can finally have config items that do not fit the key/value pair type.

    But (yes, there is one..) I have a question on the Configuration block: in all the examples, quickstarts (haven’t looked at hands on yet), I see that all the config files given (the ones with the actual info in them), there is always one section in it. I have not found one ewxample where you have several config sections in one config file.

    My app is constituted of a group of .EXE files, sharing a bunch of satellite assemblies (in DLLs). The real meat of the work is done in the libraries. I don’t want to track a whole bunch of different app config files, copying in each the config info for a given DLL, so I created one master config file with several section, and each dll reads the section of interest. I, on the other hand , have only one config file to maintain.

    I would like to use the Configuration Enterprise library for more advanced config items, but I can’t figure out the multiple configsecions thing.

    Is that possible with the ENterpriseLibrary? Could you point me to an example, if it is?

    Thanks for all the code!


Skip to main content