Tuesday, January 10, 2006

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

4 Comments:

At 1/11/2006 9:56 AM, Blogger Mary Pilon said...

Toni,

Unfortunately I do not have any success stories to share. But, I fully agree that some simple tools to automate testing would be wonderful.

I gave your TestViews program a try and once I took care of pathing issues was happy to not have any errors reported. Oh, the code you posted needs one little fix, appears "VIEW" got cut off in the following line:

lnViews = ADBOBJECTS(laViews,"

Would this be a good project idea for SednaX ?

Mary

 
At 1/13/2006 6:36 AM, Blogger raezz said...

Hi Toni,

as the lead developer of FoxRunner I would be very interested in your comments about learning curves, user interface issues and so on.

Why not start using FoxRunner 3 by creating an testing project, writing such small programs like "TestViews" and manage them with the FoxRunner 3 Testmanager utility? Next using the "Build,Deploy&Run" function of the FoxRunner 3 menu to start your VFP app under test in a second VFP instance and then go on step by step as you become more familiar with the concept and features that FoxRunner 3 offers for automated testing.

Sure it's a learning curve but it's worth the costs. I'm using FR3 not only to test VFP applications.

Thanks for your comments and best regards from Berlin, Germany
Manfred Rätzmann

 
At 1/13/2006 8:50 AM, Blogger Toni M. Feltman said...

Thanks for the correction Mary. I have to work on this template a little so that things don't get cut off or stretched out oddly. Posting this code was not the easiest thing, and I know HTML. :-)

 
At 1/16/2006 3:53 PM, Blogger Toni M. Feltman said...

Ok, I am going to get in contact with Manfred and give FoxRunner another shot.

 

Post a Comment

Links to this post:

Create a Link

<< Home