Michael Zuskin

Common Development Ideas

Mark unsolved problems

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'.

Username and password - automatically

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:

Helper files

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):

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

Unit Test Cases doc

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:

Window AAA # Open window AAA (menu "Open > …..”).
# Insert record into the upper data object and save.
# Close window AAA.
# Open window BBB (menu "Open > …..”).
# Add new record in data object "...".
# Field "bububu" enabled and contains focus.
# The dropdown list of field "bububu" contains the value inserted in window AAA.
Record deletion # In the dropdown list of field "bububu" select the value inserted in window AAA and Save.
# Close window BBB.
# Open window AAA.
# Try to delete the previously inserted record.
# Impossible - a message displayed. __
- # Close window AAA.
# Open window BBB.
# Field "bububu" in DW "dw1" disabled. __
- # Delete the previously inserted record from data object "...".
# Save.
# Close window BBB.
# Open window AAA.
# Try to delete the previously inserted record.
# The record deleted, no message displayed. __
Save # Save.
# Close the window.
# Re-open the window.
# Find the previously saved record.
# All the saved values appear. __

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:

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

blog comments powered by Disqus