Lesson 7. Testing.
In testing a virus on your own system, you subject it to
many continuous attacks - maybe even ones that are unintended. There are some rules to
follow to be sure that you can keep track of it's location and make sure it doesn't
destroy your work in the process.
1. SysBeep debugging. I'm sure most of us a pretty familiar with this technique. It's
compatible on all systems, and it's an aural identification. No visuals to set up, no
extra resources. Simple SysBeep(0); is sometimes enough to know that everything's all
right. When testing your duplication code to find out when it actually happens, use
SysBeep after each one and then check to see where it went.
2. Modification dates and times. If you use random selection of files to infect, it
becomes rather difficult to find which one got infected. If you know when an infection
happened, you can immediately check the modification dates of all files - simply by using
the FindÉ command in System 7's Finder.
3. Text Files. This could be known as a common-file technique. For testing purposes, use a
mechanism that whenever an infection takes place, the virus writes the process and the
file names and such into a common file in a common folder somewhere. This way, you can
check the text file afterwards and know exactly what your code has done. You need not make
the mechanism too elaborate, as it will only be for use in testing.
4. Backup, Backup, Backup. The thought police are at it again. In these cases, it's all
too familiar. A trashed project is no fun.