Guidelines for creating a small self-contained reproduce case

If a user contacts tech support, they might be asked to provide a small self-contained reproduce case. A small self-contained reproduce case is a small program that can be easily transferred and executed on a different system. These programs can be really useful because they usually help Tech Support understand the user's problem better than any description. Some recommended guidelines to creating a small self-contained reproduce case are shown below:

1. ISOLATE the part of the program that is causing the issue  
2. Eliminate all lines of code that are unnecessary to reproduce the problem.
3. Use as few routines and external files as possible.
4. Please do NOT include EXIT calls in your reproduce case.
5. Please do NOT send your entire application.
6. If your reproduce case requires a large amount of code (such as hundreds of lines), then you should probably try to simplify it further.

ISOLATE the part of the your application that is causing the issue

It is very important for users to determine which part of their application is causing their problem. This is important because, to create a reproduce case, they will need to determine what IDL commands are being used when the problem occurs. One way to do this, is to use the debugger in the IDL workbench to try to isolate the lines of code. A procedure to do this is shown below:

1. Put a break point in the function that first runs when your application launches. If program is a widget, put the breakpoints within each of the event handlers as well.
2. Start to run the program.  The program should stop at the break point.
3. Click the "Over" button in the workbench to step through the program until the problem occurs.
4. If the line where the error occurs is calling user defined routine, place a new breakpoint at the line determined in step 3.
5. Run the program again and let it reach the breakpoint generated in step 4.
6.  Use the "In" to step into the routine, and step through the code until you reach the line in which error is occurring.
7. If the a user routine is be called on the line the error is occurring, repeat the procedure until you reach an IDL routine that might be causing the issue.  

NOTE: Depending on the nature of the problem you may be able to use the SCOPE_TRACEBACK function instead of steps 4-7.

Use as few routines and external files as possible.

Since you are more familiar with your code than the support engineer, you are much more likely to be able to determine the important parts of your application.

Eliminate all lines of code that are unnecessary to reproduce the problem.

Usually, the clearest reproduce cases use one or two routines and generate the data within the program instead of reading from a file.

Please do NOT include EXIT calls in your reproduce case. 

If the question you are posing is about the EXIT routine, please include it in the reproduce case. If this problem the issue is not related to the EXIT routine, please do not include these calls in your program. Otherwise, this routine might cause the program to appear to be crashing when it is not. 

Please do NOT send your entire application. 

Most applications can be complex and have multiple routines that call one another. This can cause of the problem can be unclear. 

If you reproduce case requires a large amount of code (such as hundreds of lines), than you should probably try to simplify it further. 

Sometimes a lot of code is needed to reproduce a problem. However,  the longer the code is, the harder it is to understand and decipher.

Published 12/6/2013 DS, review 12/16/13 by JU, FS and KK