[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ]

*Internal object-state and application-state reporting mechanisms

Can your code provide sufficient information about itself, about current data and object state, as the tester moves through a scenario and performs regression tests? Creating these mechanisms is the province of programmers, strictly speaking. However, testers must be aware of these mechanisms and learn to trigger them -- ideally, at any moment during automated testing -- for these mechanisms to do much good. In the section on automated testing, below, I'll present an intra-VFP tool that will allow you to trigger such mechanisms.

I'd like to refer you to some excellent code and class design ideas by Steven Black, available in your \TESTINFO folder as S_BLACK.TXT, for one approach to this type of reporting mechanism and how you might build it into your classes. (Contact Steven at mailto:steveb@stevenblack.com.)

To what Steve says in this note, I'll add that I have some performance reservations about this sort of instrumenting, and you may also. But these reservations are not serious. You simply need judicious use if #IF/#ENDIF preprocessor directives to make sure that unneeded code is not generated and that unwanted calls are not made. (I don't think it's sufficient to simply RETURN quickly at the top of instrumenting and testing methods like these; to avoid performance problems, I don't even want the calls made.)

You might think of a #DEFINE trick in your top-level #INCLUDE, and do without any additional adjustments in the rest of your code. Assuming that the SelfTest method in question is not part of the published API of the object -- is accessible only internally, the trick might go something like this:

    *** in your top level header file:
    #DEFINE MY_DEBUGGING_SWITCH  .F.
    #IF MY_DEBUGGING_SWITCH
        #DEFINE THIS_TESTING   THIS.SelfTest
    #ELSE
        #DEFINE THIS_TESTING   NOTE
    #ENDIF
    ***** in your class code
    DEFINE CLASS myobj as custom
       PROC Init
          THIS_TESTING(" Init" )
       ENDPROC
       PROC SelfTest(tcArg)
          WAIT WINDOW tcArg
       ENDPROC
    ENDDEFINE

Automated Testing and VFP

Since testing takes time and resources, it only makes sense to avoid wasted resources and time in testing. Automated testing techniques have this benefit.

Some pros and cons

Automated testing also, I've observed, has the benefit of reducing emotional investment in this emotion-laden process. The automated test is harder to get mad at, and provides a more consistent response, with affect-less reporting, than other types of bug reporters. Between the general stress of application development and the " performance anxieties" that bugs represent for many developers, anything that can reduce the emotional hazards of the testing and bug reporting process has to be a Good Thing. I'd go so far as to say that automated testing is an important part of improving your development process, full stop.

However, I've also observed that people put a little too much faith in automated testing at times.

Automated testing does not mean you don't have to think about testing. Nor does automated testing save you a great deal of time -- at least, not initially.

Designing automated tests take a lot of time up-front, even though they may save you time down the road. This is analogous to the fact that designing a really good abstract class, to fulfill many requirements, takes a great deal of up-front time, even though its subclasses may be easy to write. Another similarity is that automated tests, like good abstract superclasses, take a lot of experience. You're going to do this wrong, the first three times out; it's like OOP all over again <g>.

Even when you have set up a well-defined and robust automated testing process, and know your automated testing tools inside and out, it still takes time to create the scripts, customized for each application or each test scenario, for your automated testing tools to run. This fact seems to be true no matter what tools you use.

You still have to think. And it still will take you time. But automated testing can be more consistent, more objective, and more productive than not doing automated testing. With this in mind, we have to think about how we can implement this practice in VFP.

Automated Test Options in VFP

Your options will break down into the following groups.

Intra VFP automated routines

These have the benefit of allowing access to any VFP commands and methods (from Steven Black's object methods to a LIST STATUS TO <file>) you wish to use to " peek" at object states or other status indicators, at any point within your application. They also have the benefit of working with VFP's non-standard controls. They often do not work well with ActiveX controls.

Extra-VFP automated script runners under the Windows OS

These work really well with ActiveX controls (or most of them), but you lose the benefit of running VFP code as described above.

Many of them also tend not to work with VFP's own control set. For example, Visual Test cannot work with VFP's so-called " painted controls" without some astounding, and somewhat limited, trickery. The \TESTINFO folder contains VIS_TEST.HTM, a file that describes why Visual Test commands ordinarily used to perform standard actions on controls (such as Click) do not work with all VFP controls. (Incidentally the problem occurs in Word 95 and Access, too, we aren't the only mavericks.)

Instead, you can use Visual Test's " scenario recorder" , as explained in this article, to capture the actions, and then use Visual Test's " Play" command to play back the appropriate actions. However, this method is limited by the fact that it relies on physical coordinates of these controls rather than truly addressing the controls themselves. It hardly uses Visual Test's full set of features and facilities.

Visual Test is not capable of being an OLE Automation client, and therefore can't control VFP using VFP as a server through normal means. However, your \TESTINFO folder also contains an article by Calvin Hsia, C_HSIA.DOC, in which he describes a method of invoking Visual FoxPro commands from a Visual Test Basic script. Visual Test loads FPOLE.DLL, where VFP's OLE-server capability actually resides. Thereafter Visual Test can access FoxDoCmd and FoxEval from FPOLE.DLL.

I must tell you that I have practically no experience with this technique -- and absolutely none in VFP 6 -- but I recommend that you think about using these ideas if you want to use Visual Test with VFP. I think that using this in combination with the " scenario recorder" facility might give you something usable.

As an alternative, I have been successful with a shareware automated playback device called Macro Scheduler (shown below). You'll find some information on this tool in \TESTINFO\MSCHED.TXT as well, and there is quite a bit of information on my work with Macro Scheduler in tandem with Runner, described later in this section, in the Runner help information.

In Windows 98 and the latest versions of IE, there appear to be scripting facilities that take the place of the old DOS Batch language. I have little hard information about this to share with you, as yet, and even less information about how I'd recommend you integrate them into your VFP testing routines. However, this is an ever-changing field and I am looking forward to learning more about these facilities soon.

Macro Scheduler is a shareware application for Windows scripting that successfully integrates with VFP Runner scripting with a few tricks.

Extra-Windows automated tools

The " high road" of this group of tools is an integrated hardware-software approach that is " non-intrusive" (outside the operating system). A testing tool of this nature can be said to be most " objective" because it's outside the normal system's running resources. It also has the benefit of being blind to VFP controls' differences from standard MFC Windows control classes. In fact, one such tool (AutoScriptor by Automated Solutions, Incorporated), makes a point of including VFP among the " non-standard" applications it supports.

On the downside, such a tool is necessarily expensive, and can be somewhat cumbersome to set up and implement. Since it is outside the operating system, also, it mimics user interaction with the application (keyboard and mouse) but cannot use any other system calls or influence the application in any other programmatic way.

You'll find some limited text about AutoScriptor and Automated Solutions in the \TESTINFO folder (AUTOSCR.HTM and ASITEST.HTM). If you are interested in this solution I urge you to contact http://www.asitest.com directly, for more information

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ]