CS 112 Project 1: Test-Driven Development

Objectives:

  1. Practice using TDD.
  2. Practice building methods.
  3. Practice using C++.

Introduction

This week's project is to use test-driven development (TDD) to finish the PlayList project for our company. To do so, you are to use TDD to test and build the following methods:

Note that with the exception of the save() method, most of these methods can be quite short (1-3 lines of code). Don't make them more complicated than they need to be. You should review the methods listed in the vector API, as you will need to use some of them.

You are to use test-driven development for this project; for each method:

  1. create a test-method that tests the method, and then
  2. write the method to pass the test.
A significant portion of your score will be based on the effectiveness and thoroughness of your test-methods.

You are also to design and build an application that provides a textual, menu-driven user-interface that runs in a console or Terminal window that your boss can use to interact with a playlist. This application should let your boss search the playlist by song title, artist, and/or year, add a song to the playlist, remove a song from the playlist, and save the playlist. For example, your application might display:

   Welcome to the PlayList Manager!

   Please enter:
      1 - to search the playlist for songs by a given artist
      2 - to search the playlist for songs from a given year
      3 - to search the playlist for songs with a given phrase in their title
      4 - to add a new song to the playlist
      // ... other options ...
      0 - to quit
   --->
Alternatively, you might have the user enter characters ('a', 'b', 'c', ...). Your program should use a loop that displays the menu, reads the user's choice, and performs the corresponding function, until the user chooses to quit.

As in the lab exercise, you should design this application using object-oriented design. (Hint: the word application is a noun, so you should build a class for it.)

Each file should contain opening documentation providing the who, where, when, what, and why information for that file. Your should use good programming style and make your code self-documenting in terms of identifier names, vertical and horizontal white space, etc.

Finally, each non-test-method you write should be preceded by a comment that explains what the method does, and lists its parameters, return values, any preconditions (what must be true when it begins), and postconditions (what is true when it finishes). Use the documentation from the lab exercise methods as a model.

In general, constructors and void methods should include a postcondition that indicates what is true when the method terminates. Non-void methods should indicate what value(s) they return. Some methods may need to specify both a postcondition and what they return.

One reason we do this is because tools like Doxygen (for C/C++) and JavaDoc (for Java) can process such comments and automatically generate HTML documentation pages like the C++ API. Think of this as practice for when you start using such tools.

Submit


CS > 112 > Projects > 01


This page maintained by Joel Adams.