Tips and Tricks


In addition to providing a test first environment, VFPUnit may also be used in a very interactive fashion.



	



	





********************
Use the Test code to build forms.
Try something like this in the test code:







lcMyForm = 'C:\MYFORM.SCX'
MODI FORM (lcMyForm)








The program will halt until the Form designer loses focus.  You can still
do a surprising amount of work to a form without it's losing focus.
You can add controls, properties and methods, format, size and align, edit code..,

This is also handy when designing reports, labels or other output.



	



	





and this becomes even more useful with tests.

* Note: Size the 'Test Results' window rather large.  You'll want to see the results when the designer opens,
*  but you can't resize the results window without the form designer losing focus and closing.







lcMyForm = 'C:\MYFORM.SCX'
DO FORM (lcMyForm) NAME loTmp LINKED

*- write tests against the form
loTmp.caption = 'Hello'
TEST(loTmp.caption == 'Hello', 'Unable To Set Form Caption')
*- and meaningful ones too...
loTmp.cmdEdit.Click()
TEST(loTmp.lEditMode = .T., "Edit button did not set form's Edit Mode Flag to .T.")
TEST(loTmp.cmdNext.Enabled = .F., 'Next Button not disabled during edit mode')

*- release the form
RELEASE loTmp

*- the results of your tests are now visible, so go about fixing them.
MODI FORM (lcMyForm)








rem or remove the MODI FORM (lcMyForm) statement when you are done, and you'll have regression
tests prepared for that form.



	



	





And even more so with the use of fixtures.
Since fixtures collect related 'services' with the intent of sharing, you can start to see
fixtures as acting as bizobjs, or at least a facade on a portion of a bizobj.
This example is as basic as I could think of, I'm sure you can do better...







*** Fixture Code ***
** Fixture class Properties
cAlias = 'MyData'
cTable = 'C:\MYTABLE.DBF'

** Fixture Setup
SELECT 0
USE (this.cTable)  SHARED AGAIN ALIAS (this.cAlias)

** Fixture Teardown
USE IN (this.cAlias)

*** Test Code ***
lcMyForm = 'C:\MYFORM.SCX'
*- assuming myform is expecting an alias name passed in as para.
DO FORM (lcMyForm) NAME loTmp LINKED WITH Fixture.cAlias

*- write tests against the form
* ...,




	



	





********************
I'm sure that by now, you have realized that just about anything can be executed from within
test or fixture code.  You could even use it to run batch type processes, and provide custom feedback.







lcEdiFile  = CHECK_FOR_EDI_BATCH()		&& public function that returns a pending input filename.
llHaveFile = !EMPTY(lcEdiFile)

*- Note how filename will be stored in results details window, but not on main results window.
TEST(llHaveFile, IIF(llHaveFile,;
                      'Processing ' +lcEdiFile, ;
                      'No EDI File To Process')

IF llHaveFile
	lnRecProcessed = PROCESS_EDI_FILE(lcEdiFile)
	TEST(lnRecProcessed > 0, IIF(lnRecProcessed > 0,;
                                  'Processed ' +ALLT(STR(lnRecProcessed)) +' Records From ' +lcEdiFile, ;
                                  'No Records To Process in ' +lcEdiFile)

ENDIF
* ..,
*  instead of just accessing public functions or procedures (like CHECK_FOR_EDI_BATCH),
*   Try accessing the 'resources' from a fixture.








Since this type of use is radically different than the original purpose, this usage would be
best served by a separate installation of the program, to prevent processes being fired during testing.



	



	





********************
For those comfortable with the debugger, there is a built in keyword 'STOP',
that causes the program to open the debugger, and suspend.

Sorry, setting breakpoints in the test and fixture code windows has no effect.
The breakpoints are lost when the code is internally assembled into a class definition.

On the plus side, this means that the test and fixture code windows may be edited in the
middle of running an experiment, the changes will have no effect on the current execution,
but will be incorporated the next time the experiment is run.

For the true cowboys amongst you.
  create a few objects in the test code, assigning them to private vars.
  place a 'stop' in the test code,
  open the command window, any objects you created in the test code will be visible to intellisense
   by typing the variable name and then a '.'
  use intellisense to construct any needed statements, and cut and paste them into the test code.
   [I am unable to get intellisense to work in the test code window at this point, but it does in the command window]



	



	





********************
Use the #INCLUDE and #DEFINE directives in test and fixture code to standardize external components.
This is not a new trick, but rather a reminder, for it works as well with test and fixture code as
well as production code.







#DEFINE		KDataDir		"K:\TESTBED\DATA\"		&& test data

SELECT 0
USE KDataDir +'EMPLOYEES.DBF'

SELECT 0
USE KDataDir +'PAYROLL.DBF'

SELECT 0
USE KDataDir +'WORKHISTORY.DBF'

* ..,




	



	





and by extension, create an 'Include' file that contains common #DEFINES,
and that one central file can help ensure consistency across experiments.







* in (newly created) file 'c:\MyConstants.h'	&& file name should contain the full path.
#DEFINE		KDataDir		"K:\COMMON\DATA\"
*- since this can also contain other #includes, tie in foxpro.h
#INCLUDE "c:\program files\.whatever. \foxpro.h"

* in test or fixture code, add the line:
#INCLUDE c:\MyConstants.h








Use this technique for any configurable item, it is not limited to just directories, of course.



	



Next      
Previous  
Main      


  Generated 03/11/02 01:49:41 PM
Hosted by www.Geocities.ws

1