Automated Testing?

Not long ago, Rick Schummer had a blog entry about how his views never break when he changes the structures of his tables because he uses View Editor Professional. Unfortunately I am not so lucky. I make table changes all of the time that break my views. Most of this is at the start of a project when the data model is not locked down yet. I don't have problems when I add fields to my tables, but I do have trouble when I remove fields. If you add 9 other developers and many DBCs and this can get crazy.

One solution to this problem is automated testing. I have been talking about automated testing with several clients for a couple of years now. I truly believe in the concept but have yet to find a developer that has successfully implemented the automated testing of a Visual FoxPro Application. There are many products on market that can be used. Why isn't there a good solution?

I can tell you one reason that I don't have a successful Visual FoxPro automated test case study; the learning curve. All of the automated testing tools are pretty complex and require a great deal of time to learn, even for simple tasks. So instead we keep moving ahead with all manual testing. I don’t like that. There has to be a better way.

If you have a VFP automated testing success story, please share it with me. In the mean time, I am going to begin writing my own automated testing tools. These will be very simple tools to automate some of the testing I do all of the time. As I write something, I will share it with you. Something is better than nothing, right?

My first tool is a program to test all of the views in a data folder to make sure that they can be opened. If the view cannot be opened, details will be logged to a cursor. Simple right? My first pass on a fairly large application I am working on yielded 8 broken views. Now, these can be fixed and we can move on until tomorrow’s data changes come. The code is not rocket science. Anyone reading his blog could have written it, but as far as I know no one has. This simple program will save my projects a boat load of bug fixing time. I hope it is worth something to you too.

Here's the program. You will probably want to modify it to SET PATH and such but it is a start.

*====================================================
* Program: TestViews
* Purpose: Tests all of the views in all DBCs in a
* data folder.
* Author: F1 Technologies
* Parameters: None
* Returns: None
*====================================================
LOCAL ;
   lcDir, ;
   lnFiles, ;
   lnI, ;
   lcDataDir, ;
   lnJ, ;
   lnViews

CLEAR ALL
CLOSE ALL
CLEAR
lcDir = ;
   GETDIR(SYS(5) + CURDIR(),[Select Data Directory])

IF EMPTY(lcDir)
   RETURN
ENDIF

lcDataDir = ADDBS(lcDir)
lnFiles = ADIR(laDBCs, lcDataDir + [*.DBC])
ON ERROR DO LogError WITH DBC(), laViews[lnJ], MESSAGE()

FOR lnI = 1 TO lnFiles
   OPEN DATABASE (lcDataDir + laDBCs[lnI,1])
   lnViews = ADBOBJECTS(laViews,"VIEW")

   FOR lnJ = 1 TO lnViews
      SELECT 0
      USE (laViews[lnJ]) ALIAS Test NODATA

      IF USED('Test')
         USE IN Test
      ENDIF

   ENDFOR
NEXT

IF USED("Errors")
   SELECT Errors
   * You could run a report here if you
   * wanted to really automate this.
   BROWSE
ENDIF

CLOSE DATABASES ALL

PROCEDURE LogError
LPARAMETERS ;
   tcDBC, ;
   tcAlias, ;
   tcMessage

IF NOT USED("Errors")
   CREATE CURSOR Errors ;
      (mDBC M, ;
      mAlias M, ;
      mMessage M)
ENDIF

INSERT INTO Errors ;
   (mDBC, mAlias, mMessage) ;
VALUES ;
   (tcDBC, tcAlias, tcMessage)

RETURN