Preamble Testing methods (and programs) is an important part of computer programming. One way of testing is to write an interactive driver program and you manually enter input values from your test plan and you compare the resulting output values to what was recorded on the test plan. This is a necessary form of testing, although it is time consuming and it is tedious to perform the exact same set of tests twice. An alternative way of testing is to perform batch testing. In batch testing, a data file is created once and contains both the sample input value(s) and the expected output value(s). This data file is read one test case at a time by the driver program, which then sends the input values to the untested method and then compares the output of the method to the expected output for you. The driver program keeps reading values, performing tests until the end of the data file is reached. Then it prints out statistics indicating the number (and percentage) of test cases that passed successfully. Along the way, if any of the test cases failed, then the driver program would output the input values, the actual output and the expected output, along with a short message indicating that a problem has occurred with this test case. (Note: Failed test cases indicate there might be errors/bugs in the method under scrutiny or in the test plan itself.) Lab Activities What to Do? 1) Use your test plan from the RLE encoding lab to create a collection of data files to use with your driver program. The data file will contain several input values along with the expected output values. Make sure these data files will thoroughly test the decodeRLE() method, as well as the driver method. (You don't need to test the printPicture() method.) a) Likely you'll want to put each input value on its own line. b) Likely you'll want to have a comment or two as the first couple of lines in your datafile indicating what the rest of the examples in the data file are actually testing. c) Likely you'll want to have comments before each set of data in the rest of the data file. This would be a good place to record the reasons for this set of inputs from your test plan! d) Here is a possible data file sample. Notice I was consistent in putting comments at the top of the file and before each test case. Each test case is the encoded RLE, the delimiter and then the expected output, each on a line of their own. You can do what you want in terms of datafile organization - be consistent and document it! // Test file #1: Testing single delimiters but in various locations // Delimiter at the beginning *3bd * bbbd // Delimiter in the middle d*3bd * dbbbd // and many more... 2) Write a program that will act as a driver program to batch test the decodeRLE() method. Make your driver program interactively ask for the data's filename, read one at a time all the values from the data file, output the results on the screen and keep asking for a filename until the user chooses to stop. 3) You must use the supplied decodeRLE() method, not your own. (See the bottom of the next page and the zip file.) You can call it by simply saying RLE.decodeRLE() with the correct set of parameters. (It's just like when we call any Math method.) The compiled bytecode is provided for you as a jar file; no, I will not provide the java source file to you. See the last page of lab for what you need to do with the supplied RLE.zip file. a) There is a way that you can "break" the supplied code so you can test your driver programs more thoroughly. Once the supplied code is "broken" (by changing the value of RLE.decoderState to something else) some of your test cases should FAIL, which is a good thing. Here is some sample code: System.out.println("Testing RLE as a 3rd party library"); RLE.decoderState = RLE.BrokenState.Style2; b) See the included documentation for other values of BrokenState. Hints and guidelines: Remember that every program should have instructions, which includes a description of what this program does, how to enter values, what to expect, etc. Since all data files will have comments at their top (and perhaps on entire other rows too), you'll need to skip over those lines that start with inline comment characters (//). Remember to validate all input to make sure the values are acceptable. Write an interactive program. That is, give prompts, accept input, verify values, give error messages where necessary, and allow for corrections. If you want to compare a string entered against the literal "Stop" then simply test it using the equality method, e.g., command.equals("Stop"). Make good use of control abstraction. Be more concerned with what you want to do, than how to do it. It breaks the problem down into smaller pieces, each of which are easier to solve. Make good use of methods. Do not be afraid to use many methods. Boolean value returning methods are very useful in this and all programs. Remember: Each method does one simple task only. 2 LANGARA COLLEGE COMPUTER SCIENCE 1150 Use constants where you can. Remember to write method header comments with each of your methods. Make sure you fully test each of your methods at each step. public static String decodeRLE (String rle, char delimiter) Decodes any string encoded using RLE encoding. Characters that have not been encoded in the first place need no decoding and are simply transferred to the output string. However, once a delimiter is discovered in the rle string, the next thing that follows should be a (possibly multiple digit) number and the symbol after that will be the character that is used in the expansion. For example, if the rle string is "b*8abe" and the delimiter is '*' then there will be 8 a's in the expansion, thus, "baaaaaaaabe". We will assume that the encoded portion of an RLE string is well formed. That is, immediately after a delimiter is found, the next symbols will be one or more digits followed by any non-digit character, which will be used in the expansion. Parameters: rle - a string that contains an RLE encoding delimiter - the character that signals the next series of characters need to be decoded Returns: the decoded string Batch Testing Lab // reason 1 RLE Delimiter Expected output // reason 2 rle Multiple datafiles with multiple testcases in each (based on existing Test Plans!) class RLEDriver { readWholeFile() { Loop } readOne Test CaseAtATime readOne Test CaseAtATime() reason R, D, E- } Expected RLE.decodeRLE(R,D) * Full documentation is on the last page of the lab. Actual Does expected output match actual? If so, record that this test case passed. If not, it failed; show reason, inputs, and expected and actual outputs. How to use the RLE.zip file? The supplied zip file contains two things - a RLE.jar file, which contains the bytecode for the required RLE classes, and an entire folder containing the complete documentation for these classes. The documentation you can view with your browser. The jar file needs to be 'installed' into your Java development environment. The 'installation' details will vary from one IDE to another, but will be something like the following. Command Line You'll need to specify the classpath so it knows where to go looking for the library. javac -cp path/to/RLE.jar java -cp ./:path/to/RLE.jar sourceFile.java byteCode Often you can make your life easier and put the jar file into the same place where your source code is less to type! In the second command above, the part after the -cp flag shows that there are two paths that need to be examined. The first is ./ which is the current folder, and then within the jar file itself. In this case the colon (:) is just there to separate the two paths. VSCode You'll need to create a Java project and put the RLE.jar file into the lib folder. From there you should be able to create and run your program as normal. Other IDES Not sure. You're on your own, but let me know how you make out and I'll incorporate your instructions into this lab next time. I expect you'll somehow need to include a 3rd party library into your project and then let your compiler know that it's there. If All Else Fails Unzip the jar file and just put the .class files into the same folder as your own bytecode. It should work, but will be more fiddly for you.