|
| Discussion | |
From: mda
Keywords: XFormDBF, ChangeReq, Suggestion
Remote Name: 24.147.232.222
Remote User:
Date: 02/09/01
Time: 11:50
Thanks for the detailed description of procedures I can use to perform tests on my local machine, but what I'm after is precisely the case that you are not addressing: standalone testing on BioHazard, runnable from the pcANYWHERE server machine. When I say "standalone", I don't mean on my local machine, I mean as a free-standing modular unit, disconnected from Job Control. That's why each of my apps has it's own shell and/or self-contained demo. When I deliver updates to BT, I've already tested them in my own local development environment. Then I set them up on BioHazard and test them again, as standalone apps, in BT's networked environment. But the test cases that I use, i.e. the metafile-based configurations, are very simple artifical tests. Now, I'm asking you to supply some more authentic sample configurations, which can be used for more comprehensive standalone testing. You should pick some configurations and test them yourself to confirm that the latest versions of all my apps are working satisfactorily, in standalone mode. Since BTCrit also depends on my updated apps, you should also test this out, in standalone mode. I've asked you not to put your test configurations directly into my own application directories, because that runs the risk of their being clobbered by my updates, and it also could interfere with my own independent testing activities on the BT server. The idea here is that we should make it easy to test changes to my apps and BTCrit using the latest versions of my libraries, without disrupting the global libraries that Nancy uses for Job Control. We can't go making updates to libraries that Nancy uses without her prior approval. My libraries, mdacomm, errhandl, commandr, saver, querier, reporter, splitcon, and xformdbf, should only be changed by me. Now I'm saying that you should take responsibility for setting up and testing the following new subdirectories of \redp\app\ on BioHazard: QuerTest, XFTest, and BTCrTest. If those names don't suit you, pick something else, but let me clarify further how each of these should be set up, tested, and maintained.
QuerTest:
Start with a clone of my Querier directory. Create additional entries in the metafile, querydf.dbf, for your own test cases. These tests should be constructed so as to operate properly in the BioHazard environment, running the usual standalone test procedure of going into the QuerTest directory and typing ? querier() from VFP command level. Supply a config.fpw file, if my usual default one won't suffice, in order to establish any required PATH setting so that any UDFs used by your test cases will be findable. Be sure that my mdacomm directory is on the path, and that it supersedes any other directory that may overlap. This will insure that if I make any updates in mdacomm, you will immediately be able to run your tests with those updates simply by rebuilding QuerTest\querier.pjx. If I make any Querier program updates, it should be possible to simply copy these into the QuerTest directory, being careful to leave your test metafile intact. Finally, supply a shortcut for launching VFP in the QuerTest directory, with the proper config.fpw to establish all required path settings.
XFTest:
Essentially the same as QuerTest, but substitute the appropriate XFormDBF counterparts. The end result should be that anyone can go to the BT server machine, whether directly or via pcANYWHERE, and double click on an icon that launches VFP properly in the XFTest directory. From there one should be able to type ? xformdbf( ) and run the latest standalone version of this application, using your test cases.
BTCrTest:
In this case you would start with a clone of your own BTCrit directory, not with a clone of mine (which I put under ...appl\btcritmda). You should supply sample configurations that can be run in standalone mode, and along with that the necessary config.fpw and launch icon to run in standalone mode. This means that one should be able to type ? btcrit( ) from VFP command level to run the app against your test cases.
Establishing such a standalone testing environment on BioHazard, and proceeding with this testing ASAP is extremely important to our release 1 objectives, so I think you should proceed as I have outlined without delay. This is not only more important than any further work on optimizations, but it is also a crucial first step towards undertaking further development of these applications, including optimizations, which will follow release 1.
|
|
|
|
| Contents | Discussion | |
|