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:

• a Song::operator==(const Song& song2) const method that returns true if the Song to which this message is sent is the same as song2; and returns false otherwise. Your method should:
  • return true for songs that are the same;
  • return false for songs that differ only in the title (i.e., different songs by the same artist in the same year),
  • return false for songs that differ only in the artist (i.e., songs covered by a different artist the same year), and
  • return false for songs that differ only in the year (i.e., the same song released by the same artist in a different year).
  Your test method should check each of these cases.
• a PlayList::searchByYear(unsigned year) method that returns all songs in the playlist that were produced in the given year. Your test-method should use the 4-song testSongs.txt file we used in lab01, and check for the years 2015, 2012, and 1967.
• a PlayList::searchByTitlePhrase(const string& phrase) method that returns all songs in the playlist that have phrase anywhere in their title. Use what you have learned in this week's lab to write a strong test-method.
• a PlayList::addSong(const Song& newSong) method that appends newSong to the playlist.
• a PlayList::removeSong(const Song& aSong) method that removes aSong from the collection. You may want to use the same test-method for this and addSong() -- since they are inverse operations, they can be used in combination to leave the playlist in its original state.
• a PlayList::save() const method that writes the playlist back to the text file that was used to construct the collection. Think carefully about how you can write a good test method for this operation -- it takes some work, but it can be done.

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.

Application

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
   --->

As in the lab exercise, you should design this application using an object-oriented approach. (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.

Preparing to Submit

Create a script file, in which you: (i) use the ls command to list the files of your project (all .h, .cpp, and .txt files), (ii) use the cat command to show the contents of each file, (iii) show that they compile and link correctly, and (iv) show that they run and solve the project-problem completely and correctly. Make certain that this script file is inside your Eclipse project folder, so that that folder contains all files related to this project.

Submit

• A fully functional electronic copy of your project folder (including your script file, all source files, and any test files they use), in a folder named /home/cs/112/current/yourUserName/proj01 (replacing yourUserName with your actual user-name). The grader will grade your submission according to the categories specified on this grade sheet.

CS > 112 > Projects > 01