Michael Zuskin

• Mark unsolved problems
• Username and password - automatically
• Helper files
• Unit Test Cases doc

When you find a problem place in a script, but don't want to fix it immediately (busy with something else or have to depart to Hawaii after 3 hours) - mark that place with your personal marker string (of course, as a comment). For example, my personal marker is "???mz" (by the initials - to prevent conflict with markers of other developers). And don't forget to describe the problem in a couple of words - help yourself in the future! Of course, you will forget about the marked places (especially after Hawaii), but the Global Search of your marker will take you directly to the forgotten problems. Perform that search when you have done the development and are going to check the objects in - to make sure you haven't leave any 'holes'.

Many of us, developers, work on applications which allow users to log in only after entering username and password (and, sometimes, database environment). I see that many programmers, having been working on their projects for years, on each application start enter username/password/DB env manually as if they would enjoy that. When those developers make changes in the code (or in the layout) many times and after each change launch the application to see the results, they docilely repeat the manual login data entry - time after time, time after time! There are two major ways to automatize that boring and not needed action:

• Set up username and password in your code - fill the appropriate text boxes (as if the values would be typed by human) or directly populate the variables which take the values to the futher processing) and programmatically fire "clicked" event of the button "Login". It's better to read the security parameters from a file (instead of to hard code) so you can easily change them if needed. Nice if that functionality is impemented in your application so all the developers can use it, but if not - you can create it for yourself individually. For that, a class, containing the login code (like a small login window), must be copied to your local library which is placed before the original library of the class in the application's Libraries Path and is not over-written when you refresh the source code from the central storage. But it has a potential problem: if the original class will be changed in the future, "your" copied version will "hide" those changes. Another problem - if you work with multiple versions of the source code then you need to perform the described action in every version.
  
  
• There is a much better approach - using a special program to imitate human's actions (keystrokes and mouse clicks) with help of macros. I am using a program named AutoHotKey - go to the site and read about it. Shortly, you create macros in a special text file, and launch them with selected keys combinations. For example, I have programmed my macros to enter username and password when I click Alt+W, while the combinations Alt+Q, Alt+A and Alt+Z insert different DB environment and just after that "click" the "Login" button (these keys have no meaning - I have selected them because they are placed very convenient for fingers). If you want to login under another user (for example, to test a security feature with users having different privilegies) then you can create additional macros, or even to enter data manually (if you are not planning to utilize that user a lot).

The next stuff is not about just elegant code, but I decided to include it because it is in the frame of the article task - to facilitate programmers' lives... Usually our work consists of tasks that last from hours to months (normally a number of days or weeks). For each task I open a folder in my area in the corporation net (which is backed up nightly) - it will contain all the stuff related to that task. The names of the folders consist of 2 parts: a number (starting with 001, for correct sort by time) and a description (which will help to find a desired folder later). Here are examples of names: "002 Training Views - change source tables", "004 Log Reports". Every such folder contains (as a standard):

• Sub-folder "SQL" for scripts which should be applied to the database (such as CREATEs, INSERTs etc.).
  
  
• File "_obj.txt" into which I write every checked out object. The file is divided into small sections for each library (or schema - for DB objects). Each object has its own line in a section, consisting of 2 columns: object name and short description of changes made in it while doing the task (later, when I check these objects in, I copy that description into the Version Control software's "Comments" field). The file structure is like the following:
  
  

  AAA_library:
          class_1                 Description of what is made in class_1
          class_2                 Description of what is made in class_2
          
  BBB_library:
          class_3                 Description of what is made in class_3
          class_4                 Description of what is made in class_4
                                  
  XXX_DB_schema:
          db_object_1             Description of what is made in db_object_1
          db_object_2             Description of what is made in db_object_2
          
  YYY_DB_schema:
          db_object_3             Description of what is made in db_object_3
          db_object_4             Description of what is made in db_object_4

  If I check in all the classes of the task and after that check some of them out back (for example, to work for the next release, or to fix a found problem), I open a new section in this file. Why? Because it's in fact "other story" (from the viewpoint of check out - check in process). Managing of this file is especially useful when I check out classes for different tasks in the same time, mixing them in one "check out" library (like PBL in PowerBuilder) - when I want to check in classes of only one task, I simply "go" by the file, having no chance to forget classes or to check in classes belonging to other task.
  
  

• File "_misc.txt" for remarks - usually I do a lot of them.
  
  
• Shortcut to file "_todo.txt" - to write all the delayed stuff which should be done in the future (like "When Bill Gates will check in BlahBlahBlah class, find "???mz" in its BlahBlahBlah method and...."). I have only one such file that serves different tasks (only the shortcut is copied each time a new task begins) so I see all the pending changes in one place (I tried to have "todo" files for each task, but it didn't work: I never opened it after the task was completed!).

And, of course, each folder has additional files if needed; they appear AFTER the described files whose names begin with underscore.

Each time you create a new application unit (like new screen or process), create in Word the "Unit Test Cases" document which is, in fact, a table with step-by-step instructions of what you have to do and which results should be gotten (and 'OK' column to mark success or failure of this step's testing). Here is an example of such a table:

The column "TESTED ITEM" gives a short description of the functionality being tested in the row. If a test is described in more than one row, it's enough to write the description only once and leave that field blank in the subsequent rows (in the given example, 3 rows describe testing of a record deletion, but "Record deletion" appears only in the first row of the three).

Important! The field "EXPECTED RESULTS" should contain only results, interesting from the viewpoint of the current test! If something happens as result of your actions, but is not the subject of the current test, write that in the "STEPS TO PERFORM" column. For example, if button "Cars" opens window "Cars" and it has been working for years (not being tested now!), write:

# Click button "Cars" - window "Cars" opened.
# Click button "Add"...

Or this way:

# Click button "Cars".
# In opened "Cars" window click button "Add"...

But if you have just developed the window "Cars" and are testing how it is opened, then write in the "Steps" column:

# Click button "Cars".

And in "Expected result":

# Window "Cars" opened.

It will take time to create such table each time, but it will save more time! These documents are integral part of the project (exactly like programming language code), and you don't say "no, I will not write code because it takes time!", right? If writing of "Unit Test Instructions" documents is not a habit in your work place, give your manager that idea! Tell him/her about the following advantages:

• It makes work of QA person easier and faster, with no guessing and foggy suggestions how the unit must work.
  
  
• Helps the developer restore in memory small details of the development which was done a couple of days long-long time ago.
  
  
• Sometimes writing the document highlights problems or raises good ideas about the development (now you can more concentrate on WHAT is being done, and not HOW technically implemented).
  
  
• Writing the document BEFORE development (and building the application module BY the document) enables to see problems (and solve them) in an early stage. It’s easier to re-write a Word document instead of re-create an already built and partly tested application module. So, write the doc, give it to the business people you have gathered information and refined requirements from, and ask them to imagine that they are testing the already developed application unit. If they will want to change/add/remove something - run to your MS Word, change the doc accordingly and run back to the business guys. Perform that algorithm in loop (use stairs if these guys are sitting in other floor - very healthy for developers having a sitting job!) until the document is looking like its final version, and only after that begin the implementation in code.
  
  
• Unit tests, performed from time to time by such documents, help to make sure the unit is not affected by changes in (and adding of) other modules ("regression testing").

Shortly, it saves headache to you and money to your company.