Return to mstest32.txt CVS log

Up to [WindowsNT SDKs] / mstools / mstest

Annotation of mstools/mstest/mstest32.txt, revision 1.1

1.1     ! root        1: HINTS FOR CREATING SCRIPTS FOR 32-BIT MICROSOFT TEST
        !             2: 
        !             3: This file describes differences between using Microsoft Test on 16-bit Windows
        !             4: vs. 32-bit Windows (NT).  There are some areas where special code must be
        !             5: placed into the scripts in order for script to successfully run under NT.  In
        !             6: almost all cases it is possible to create the scripts such that they will run
        !             7: properly under both platforms without modification.
        !             8: ------------------------------------------------------------------------------
        !             9: 
        !            10: Due to differences between Windows 3.1 and Windows NT, MS Test scripts
        !            11: written for 16-bit (Win 3.1) may not run under 32-bit without modification.
        !            12: This file will explain some of the most common reasons for this and provide
        !            13: ways to workaround the problems with simple modifications to scripts.
        !            14: 
        !            15: The primary difference is preemption vs. non-preemption.  Under 16-bit
        !            16: windows, MS Test scripts could perform actions on an application with a
        !            17: single statement, and be assured that by the time the next statement begins
        !            18: to execute, the application has already completed what it was asked to do
        !            19: with the first statement.  For example, under Win 3.1 the code below:
        !            20: 
        !            21:     WMenu "File"
        !            22:     WMenu "Open..."
        !            23:     WButtonClick "Cancel"
        !            24: 
        !            25: ...would bring up the File.Open dialog and cancel it without any problem.
        !            26: 
        !            27: (Note that this is *most often* the case -- there are cases in Win 3.1
        !            28: where the application "yields" while performing a task, in which case the
        !            29: script writer must take special steps to ensure that task has completed
        !            30: before continuing with the script.)
        !            31: 
        !            32: However, the same code run on 32-bit windows will bring up the File.Open
        !            33: dialog, but the WButtonClick function may fail because the File.Open
        !            34: dialog may not be there yet.  Since NT is a preemptive system, both
        !            35: the application and the script run concurrently -- and if the application
        !            36: takes longer to bring up the file.open dialog than it takes MS Test to
        !            37: execute the WButtonClick call (which it often does), WButtonClick will
        !            38: fail to find a "Cancel" button, the script will continue on, and we will
        !            39: have effectively "lost" an important event.
        !            40: 
        !            41: USING THE WFndWndWait FUNCTION:
        !            42: -------------------------------
        !            43: To combat this, 32-bit scripts need to WAIT for things to happen.  By far,
        !            44: the best way to do this is to use one of the new TestCtrl API:
        !            45: 
        !            46:     h = WFndWndWait ("Open", FW_PART, 5)
        !            47: 
        !            48: This call will wait for a window with "Open" (or "open" or "OPEN") in its
        !            49: caption to appear, or for 5 seconds, whichever happens first.  The handle
        !            50: to the window will be returned, or NULL if it timed out before the window
        !            51: was found.  When using this api, it is safe to use rather long timeout
        !            52: values (20 or 30 seconds) because the function returns as soon as the
        !            53: window is there, and if the window is expected to come up but doesn't,
        !            54: something has gone wrong, anyway.
        !            55: 
        !            56: Calls like this could be placed in between things that might take some
        !            57: time to happen, like between "WMenu "File"" and "WButtonClick":
        !            58: 
        !            59:     WMenu "File"
        !            60:     WMenu "Open..."
        !            61:     h = WFndWndWait ("Open", FW_PART, 5)
        !            62:     WButtonClick "Cancel"
        !            63: 
        !            64: AND, to make this even easier, you could create a wrapper function like
        !            65: the following:
        !            66: 
        !            67:     DECLARE SUB WndWait (Title$)
        !            68:     STATIC SUB WndWait (Title)
        !            69:         IF WFndWndWait (Title$, FW_PART, giTimeOut) = 0 THEN
        !            70:             PAUSE "Window " + Title$ + " could not be found!"
        !            71:             END
        !            72:         END IF
        !            73:     END SUB
        !            74: 
        !            75: ...and place it in a header file.  Then all you need to add are statements
        !            76: like the following:
        !            77: 
        !            78:     WMenu "File"
        !            79:     WMenu "Open..."
        !            80:     WndWait "Open"
        !            81:     WButtonClick "Cancel"
        !            82: 
        !            83: ...and if the window you're looking for never comes up, the script will
        !            84: END, after telling you which window it couldn't find.
        !            85: 
        !            86: USING THE QueSetSpeed AND QuePause FUNCTIONS:
        !            87: ---------------------------------------------
        !            88: In some cases, slowing down playback of journalled events can be helpful, not
        !            89: only in allowing things to complete (which isn't too much of a concern, since
        !            90: NT synchronizes all input threads while journalling), but also in allowing
        !            91: you to see what is actually happening during the execution of a script.
        !            92: 
        !            93: You can do this in two ways:
        !            94:     - The QueSetSpeed statement allows you to set a time (in milliseconds)
        !            95:       delay between each message is played
        !            96:     - The QuePause stateent lets you set a one-time pause in the event
        !            97:       stream just before the next queued event.
        !            98: 
        !            99: USING THE NEW SPEED STATEMENT:
        !           100: ------------------------------
        !           101: 32-bit MS Test has a new statement called SPEED which allows you to control
        !           102: the general execution speed of the script.  It is dynamic, meaning you can
        !           103: run parts of the script at full speed, and slow other parts down drastically.
        !           104: For example:
        !           105: 
        !           106:     SPEED 100
        !           107: 
        !           108: ...will cause TestDrvr to sleep for 100 milliseconds before executing each
        !           109: line of code in the script.  Likewise,
        !           110: 
        !           111:     SPEED 0
        !           112: 
        !           113: ...will allow TestDrvr to run the script at full speed.
        !           114: 
        !           115: This can also be an easy way to keep the application under test from "falling
        !           116: behind" the MS Test script.  However, care should be taken when controlling
        !           117: the speed of execution OR playback -- as it might work okay on one system, but
        !           118: still be too fast for another.
        !           119: 
        !           120: OTHER CONSIDERATIONS:
        !           121: ---------------------
        !           122: Some special things to watch out for include:
        !           123: 
        !           124:     - Using Program Manager to launch apps under test.  Progman does NOT wait
        !           125:       for the application to come to the foreground before continuing.  Thus
        !           126:       if you use "File.Run" from progman to start your app, you MUST use some
        !           127:       way of waiting for the application to appear before continuing with
        !           128:       the script, such as the WFndWndWait method.  The best solution, though,
        !           129:       is to use MS Test's RUN statement.  Internally, RUN uses WinExec, which
        !           130:       will wait until the application appears before returning, which causes
        !           131:       the script to wait as well.  So, unless you are specifically testing
        !           132:       Program Manager's ability to launch applications, using RUN is a much
        !           133:       "safer" way of starting the app.
        !           134: 
        !           135:     - Switching between apps within the script (such as setting focus to
        !           136:       another application, etc).  You should wait for a brief moment (perhaps
        !           137:       SLEEP 1 to sleep for a second) before starting to perform actions to
        !           138:       the new app.
        !           139: 
        !           140: 
        !           141: WS1.DLL - WaitUntilIdle() FUNCTION:
        !           142: -----------------------------------
        !           143: The following function is provided in the WS1.DLL:
        !           144: 
        !           145: DECLARE FUNCTION WaitUntilIdle LIB "ws1.dll" (nMSecToWait&) as Integer
        !           146: 
        !           147: The WaitUntilIdle function waits until the forground application has reached an
        !           148: idle state.
        !           149: 
        !           150: Parameters:   nMSecToWait& -
        !           151:                Specifies the number of milliseconds the function will wait for
        !           152:                the foreground application to go idle.
        !           153:                 0  : Function tests the idle state and returns immediately.
        !           154:                -1 : Function will not return until the idle state is reached.
        !           155: 
        !           156: Return Value: TRUE  : The foreground application reached the idle state.
        !           157: 
        !           158:              FALSE : The wait was terminated because the timeout time was
        !           159:                      reached or an error occurred.
        !           160: 
        !           161: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.