Testing

• This is chapter 26 of the book, you should read this.
• There are some great quotes at the beginning of the chapter
  • A programmer has overcome a major hurdle in her career when she realizes that testing is a part of the software development process.
  • Bugs are not an occasional occurrence. They are a part of every project of significant size.
• White box testing assumes that you know the code and design the test accordingly
• Black box testing tests the code without this knowledge.
• Unit testing is the process of testing each portion of the code.
  • This is fine grain testing
  • Where the test code is not part of the final delivered project
  • But unit tests are written to assure that
    • This part of the product is working.
    • Changes implemented do not break this section of the product.
• There are other levels of testing, but that is for software engineering.
• There is a problem with our direction in testing so far
  • You are asked to test the entire program upon completion.
  • You are expected to do this by hand.
  • You are given no tools to accomplish this task.
  • 
• Your stack class is a good candidate for unit testing.
  • You have the following
    • constructor, destructor
    • copy constructor, assignment operator
    • push, pop, top
    • size, isEmpty, isFull
  • You need to test all of these reasonably thoroughly.
  • But how do you do that?
• The constructor and destructor
  • These are needed by everything.
  • In some sense you can't test them directly.
  • But it is likely that errors will be exposed in other testing.
• Push, pop and top
  • These are basic to all other routines.
    • IE if size is broken, these will still function.
    • But if these are broken, nothing else matters.
  • So come up with a way to make sure everything is working
  • Test each independently then as a group.
  • Use the three cases we used when designing the software
    • Push and pop an item on an empty stack.
    • Push and pop an item on a stack with one element.
    • Push and pop items on a stack with more than one element.
      • Do several different sizes.
  • In each case,
    • you should know what the stack should look like after each action.
    • You should check to see that it does look like this after the action.
    • more on this to come.
• In this case, you could also test IsEmpty, IsFull and Size at the same time.
• The copy constructor requires special consideration.
• The overloaded assignment operator as well.
  • These two are probably the most complex routines.
  • They are easy to test, just make sure that you do test them.
  • Make sure you consider special cases
    • a = a; in the overloaded assignment operator for example.
• He lists some advantages of well written tests
  1. They prove the functionality of code. Until you use your code, you have no idea if it works or not.
  2. They provide an alert when changing the code has broken it (maintenance, later modification for integration, ...)
  3. If the plan for testing is developed along with the design of the code, they can reduce problems from the start.
  4. They test the code as it is developed.
  5. They provide an example of how to use the code.
• He strongly believes that tests should be designed along with code design.
  • And develop the tests as you are developing the code.
  • This will aid in understanding the requirements.
  • But tests are dynamic, and should be augmented as code is written.
  • As you write code, write tests to address specific situations.
• It is very important to assure that all the code is tested.
  • This is called code coverage
  • And you should strive for nearly 100% code coverage.
  • We will discuss a tool to deal with this.
• What should you test?
  • What are the tings that this piece of code is written to do?
  • What are the typical ways each method would be called?
  • What are the preconditions of the methods and how could these be violated?
  • How could each method b e misused?
  • What kinds of data are you expecting as input?
  • What kinds of data are you not expecting as input?
  • What are the edge cases?
  • What are the exceptional conditions?
• Try to test things at as small a level as possible.
• But don't forget about complex cases.
• Remember when testing
  • You could have a problem with your code
  • Or you could have a problem with your test code.
  • You could have a problem with your design/specification.
  • Keep all of this in mind.