TestingLab

Run length encoding is a simple form of data compression. It replaces long sequences of a repeated value with a one occurence of the value and a count of how many times to repeat it. This works reasonably well when there are lots of long repeats such as in black and white images. To avoid having to represent non-repeated runs with a count of 1 and the value (doubling the required storage), a special value is used to indicate the presence of a run and everything else is just treated as a simple value. In this lab you will be provided with a buggy version of a run length encoder that is intended to meet the following specification (same as lab6). Your goal will be to create tests to identify as many errors as possible. Here is the specification:

The program should perform run length encoding on one line at at time passing newline characters through uncompressed even when there are repeated blank lines.

When a run of n>=3 repeated characters, c, is detected where c is NOT a digit, the run will be replaced with #nc.

When a run of n>=3 repeated characters, c, is detected where c IS a digit, the run will be replaced with #n#c. The extra # is needed to avoid confusing the repeated digit c with the last digit of the run count.

All other characters (i.e. runs of just 1 or 2 characters) are passed through unmodified.

Some examples:

abc compresses to abc

aaabcccc compresses to #3ab#4c

abc12333333 compresses to abc12#6#3

The Encoder.class file in Canvas Files/TestingLab contains a buggy implementation of this program. Your task is to create a set of tests that identify the 3 distinct errors in this program. You are doing "black box testing" because you are creating the tests without knowing how the problem was implemented (without "looking inside the box" so to speak).

You are to implement your tests as unit tests for the method compress() which takes a String (one line of input) and returns the compressed form as a String. Your tests should be added to the EncoderTest.java file (also in Canvas Files/TestingLab) and follow the format of the tests provided (all of which pass).

You should submit a complete test suite (EncoderTest.java), not just the three tests that fail due to the 3 distinct errors. Your test suite should be suitable for testing any implementation of Encoder. For example, it should include some basic tests such as a string with no runs or a string with just a run. You should be systematic, not just try random cases. Maybe use your own code for inspiration. What are the "corner cases"? What are some equivalence classes (tests that are all most likely testing the same code), eg a single run of 5 characters and a single run of 100 characters?

It is essential that you carefully comment/document each of your test cases so the grader knows why you included that test case. E.g.

// test that it correctly encodes a run of a digit

The template test file does not have comments because in some sense the provided tests are just some random tests. If you chose to keep those tests, add a comment to explain what it is testing. The comment above might be reasonable for the first test in the file.

A carefully thought out test suite that does not in fact find all 3 errors could still potentially receive full credit. It is more important that you have a logical, thoughtful test suite than it is for you to have found all 3 errors. I anticipate that finding two of the errors will be relatively easy. The third may be a bit more elusive.

Submit your completed EncoderTest.java in Canvas.