Lab 7: Testing

Overview

In this lab you will:

  1. Become familiar with the basic aspects of testing
  2. Gain experience black-box testing a class

Testing Introduction

Testing is a critical component of the software development process. The goals of testing include ensuring your application produces the desired output, and handles errors gracefully. Checking that your program performs correctly by providing expected and correct input is only part of the process—it’s important to test your system with incorrect and erroneous input, and to stress test it. Failing to consider these latter cases can cause you to overlook bugs that may be in your code.

Software defects can sometimes just be amusing. If you try to watch a video with an age restriction from Hulu, but the video is streamed through a different website, it is possible to successfully enter February 30 as your birthday. But, bugs can also be costly. In 2002, NIST reported that software bugs cost nearly $60 billion. They can also cost human lives— the Patriot Missile system had a floating point round-off error that got worse over time, and since the appropriate endurance tests weren’t carried out, the Patriot's ability to shoot down other missiles was severely compromised.

There are many different levels of testing:

There are several approaches that refer to the visibility of the code being tested. White box testing is where the tester knows about the inner workings of the software being tested. On the other hand, black box testing involves just the opposite—the tester knows the functionality of the system, but not how that functionality is implemented. In today’s lab, you will be black box testing a class that has already been written for you.


The Task

You must do this lab on the GL servers. This code is not guaranteed to work on any other system.

Download these files to get started: If you've ssh’ed into the GL servers through your laptop, issue the following command at the command prompt while you’re inside your lab7 directory:
cp /afs/umbc.edu/users/p/a/park/pub/cmsc202/spring14/lab7/* .
(Note the '.' at the end of the command--that is very important.)

The IntArray class contains many error statements hidden throughout its implementation. Your job will be to make at least 12 of them print out. You must find at least one error and one edge case. Errors are inputs to a method that violate its preconditions, and edge cases are inputs that, while technically valid, do not make very much sense to use as input, or they sit right on the boundary between valid and invalid inputs. You will need to look at the documented preconditions to figure out how to trigger these error and edge cases.

The goal is to get you to think about how to break the code, rather than make it work. This is a strategy you should employ when testing your own programs, in addition to simply checking if they work. Don’t always count on the happy path being taken when your programs are run.


Helpful Emacs Commands


Extra Credit‽

The main task in this lab involved trying to violate preconditions, rather than validating postconditions. In the IntArray class, both the copy constructor and assignment operator allege that they make deep copies of IntArray objects, meaning their contents are copied to new objects, and modifications to either the original or copy do not also happen to the other one.

In order to earn 1 point of extra credit, choose either the assignment operator or the copy constructor, and demonstrate that it does in fact make a deep copy of an IntArray.