Lab: Printf Testing

General Instructions:

1. Create a folder on the local machine for this lab.
2. Download the materials from above into the folder.
3. Note that the PrintfLabBug is a class file.  You will not be able to see the code nor compile it.  You will need to use the terminal window to test your code using this class.

Part A - Detailed background

Professors Harris have built a solution to the printf lab, which you see in the Materials section. But because they are devious, they have also introduced some defects.

Your job will be to build a test to find the defects(bugs) in the instructors' code (given to you as PrintfLabBug.class above). A test is a series of test cases designed to exercise the code and demonstrate defects that exist in that code. A test case is one particular test run (one set of test values).  Testing is one part of the debugging process. In this lab, your job is to identify all of the defective code in the provided appliction by designing a series of test cases to thoroughly check each of the different formats.

You cannot test every possible value through the application.  Testers sample the values based on some standard strategies.  You should:

• Choose "normal" values - what will generally be used? These are the easy cases, but you cannot neglect them.
• Choose "outlier" values - what are at the extremes of the normal value range? You should choose values at the extremes of the range.
• Choose values within each of the variants - if an application behaves differently for different classes of data, you must build test cases in each of the variants.
• Choose "boundary" values - if you are dealing with variant behavior, you need to check for those things close to the boundaries of those variants.
• Choose 0 or null - for numbers, 0 can be a problematic value...for reference types, a null can cause application problems. Be sure to test these special values.

For this lab, you will build two files for each test case. The first file will contain the input that you will use for the test case, and the second file will contain the output that you expect to see as a result. We have given you one input and one output file to use as a "starter", tst-99.in and tst-99.out respectively. Your files should follow these formats.

Part B - Designing the test cases

1. Look at the program specifications for Part B and Part C from the lab on Monday. Make sure that you "understand the problem". In other words, do you know exactly what should print for each specified output statement?
2. Download the tst-99.in and tst-99.out files which are your "starter" files. The tst-99.in file has the values in the order of String, integer, and double each on its own line. The tst-99.out file has the output which was produced by tst-99.in. The output file in this case and in your case should reflect the correct output.
3. Look at each output specification and decide what values for ss, ii, and dd are necessary for testing that specification. In some cases, the same values can be used to test several output formats. In other cases, you will need to expand the number of individual test cases.
4. Create your own tst-nn.in andtst-nn.out files (where the nn would be replaced by a two digit number, sequentially beginning with 01.
5. Use your tst-nn.in file to run through the PrintfLabBug application.  Does the output exactly match the expected output?  If not...
6. A difference between expected and actual output can indicate that either the expected output is wrong, or the actual output is wrong.  Before assuming that the actual output is wrong, be sure to go back and check your expected output again to make sure that you really understand what should be displayed.  Use your first lab as a reference.
7. As you look at each specification in section B and C, consider all of the test cases you need to thoroughly test that specification.  Don't create unnecessary tests, but do test each of the different formats. As you need new values, add additional tst-nn.in andtst-nn.out files to correspond.
8. When you believe that you have a complete test, move on to Part C.

Part C - Running the automated test

1. The printf-test.txt file contains a script that will perform an automated test using your input and output files to compare the actual output with your expected output.  If you have not done so already, download printf-test.txt to your working directory.  All of your test cases and the PrintfLabBug must be in the same directory.
2. Execute the script by typing its name on the command line.  The script will run a set of specialized test cases based on your tst-nn.in files and compare the results with your tst-nn.out files.  Th version of PrintfLabBug that is used in the test has a number of bugs.  The test run will give you an error message if:

• Your test finds a bug that does not exist.
• Your test does not find a bug that does exist. This error message will indicate which of the specifications from the original lab you failed to thoroughly test.

• Demonstrate the successful run for your instructor to recieve credit for this lab.