All posts by Peter Fitzgibbons

VS 2005 Beta 2 RTM & TDD

Ok, it’s been a while… a loong loong while.
All my projects are now in process of being converted to VS.NET 2.0. Currently using the Sept.05 CTP.
Now that a couple of the projects are deployed (using the Beta 2 go-live license, of course… only build on Beta 2… CTP’s are not licenced!) I’m going into TDD and Mocking mode. Looks like RhinoMock gets the win as currently having a build on NetFx 2.0. I’m in the less-work-win-bid category right now… all projects are officially behind due to rewrite.

So, my next post will outline a simple way to test a home-grown data-access web service.

Black Belt TDD in VB6

Ahh, testing again in VB6. Learning all about the black art of WinAPI programming and control of mouse events.

Here’s what I’ve learned that can be passed on to you, Grasshopper.

  • Test a Pop-Up menu… seek your history, Grasshopper, and learn that PopupMenu is a BLOCKING function. Therefore, a out-of-thread timer is required to handle the call. Oh, and when you get ready to SendKeys to the menu… Make NO OTHER CALLS before sending the keys, and send them all at once. The container form of the popup menu will readily take back keyboard focus and you’ll lose your menu control otherwise.
  • Testing a TreeView with Mouse Events. Getting the windows handle of the selected TreeView node requires you to go down the rabbit hole of WinAPI. SendMessage with TVM_GETNEXTITEM, TVGN_CARET and TVM_GETNEXTITEM, TVGN_ROOT will be very beneficial.
  • A nice dll out-of-thread timer can be found at

Oh, how this is fun!

Why no code? Because as a student of the black art the education is in your research, and the joy is in watching your code do what you wanted after long long efforts.

TEST DRIVEN UI – Dot Net Unit Testing UI

Hello Hello Hello,

It’s been a long time. I’ve had my head buried under several layers of black, gooey, .NET C# UI routines.

Testing UI is NOT a picnic.

I’ve found problems in two categories thus far :

1. Old VB6 tactics result in cross-updating/cross-merging of datasets. Basically MAJOR data collisions. The most common instances of this are a pair of cascading comboboxes where combobox-child has list-data one minute… and no list data the next! The hardest debugging is watching the Step-into pass over a line of code and the dataset has changed… what happened to my internals?!

2. Mocking for UI is scarily complicated. Again here is a bunch of dataset collsions, but also the need to mock the results of data processes (especially updates) for the purpose of the UI. I will note here that coding ADO.NET one-row inserts and updates with specified primary-key values is still 1000% easier than ADO!

OK, If anyone is reading my blather, feel free to comment, suggest.

I especially want to hear of your own experiences or links to other Test-Driven UI efforts.

Test Driven in VB 6

OK. Due to severe scheduling restraints (IE I’m 1 month late on this project), I am forced to run test-driven in VB 6.

With the help of vbUnit3 Framework and vbUnit-Free Add-In, the unit testing bit is setup.

VBMock provides a framework for mocking objects in vb 6. This works well. There are two notes here for VBMocking.

1.) Remember that VB 6 does NOT provide true OOP inheritance… IE “Implements” requires you to “overwrite” the super’s routines. This might be as simple as call-forwarding the super’s call, but it must be manually handled. This provides the “out” for Mocking… the mock object can reference directly the target Class.. no Interface is required. Then the MockingClass can properly mock-override the target Class routines.

2.) EXE/DLL arrangement and Modal Forms. Well, here’s the black-belt approach to VB programming. You will probably want to implement a splash-form. This form must exist on the EXE Project. ControlBox off and no Caption gives you a “windowless” splass screen. It will appear in the task tray UNTIL it is minimized. This gives you the opportunity to hand off control to the main form residing in the DLL. UNLESS you are using MDI. MDI cannot exist inside a DLL, so your EXE will contain the MDI. In this case, if you wish to employ a splash or not is up to customer requirements. In the case of no-MDI, the main form referenced from the EXE to the DLL must have an additional routine Init() to allow you to pass the reference of the splash form into the Main form…. this will prevent the Sub Main() from following the code path after the Form.Show() of your splash and then shutting down the application. Your main form must catch Form_Unload can call Unload fSplash_ in order to allow the entire application to properly exit when the main form is closed.



Well, mocking the average form is A-OK, but we don’t have the advantages of .NET Reflection here, so there is no “catching” a call to a modal form or internally handling events when the form is displayed.

The approach :

Create class “ModalForms” (I Resist the name “Dialogs” because sometimes a Modal is not necessarily a dialog but more like a dictatorial command).

Class ModalForms

Public Sub MessageBox() : Wrapper the standard MsgBox call. WHY? You need a way to Mock message boxes to the main application in order to test main-form logic. SOOO, wrappering the MsgBox allows you to send mock responses back to your main-form for TDD logic paths.

Public Sub : Same theory as above.

Oh, and another thing… you’ll notice that you need one more public class “NormalForms” that provides getters to the non-modal form objects. This is because forms are private to the project and must be manually exposed on the DLL interface so that your EXE can get them.

More Later.

New stuff

I will be documenting some of my adventures with Visual Studio .NET, both WinForms and ASP.NET. My main platform is Win2000/XP, SQL Server 2000, IIS 5. We do not perform “disconnected” application programming at my company. External intra-net access is achieved via Terminal Services.

Circle of Life

Baby Fitz still waiting.

My Grandmother, Agnes Marie Severson passed away this morning. 96.

She has been ready to die for a couple years now. We’re glad her spirit is free. I believe that her spirit has met Baby Fitz. Somehow baby may understand “GreatGrandma” differently than others.

So, Baby Fitz, you’ve met GreatGrandma now. When are you coming to join US?!