CS 112 Project 1: Test-Driven Development
- Practice using TDD.
- Practice building methods.
- Practice using C++.
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
as you will need to use some of them.
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:
Your test method should check each of these cases.
- 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).
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
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:
A significant portion of your score will be based on the
effectiveness and thoroughness of your test-methods.
- create a test-method that tests the method,
- write the method to pass the test.
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!
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
(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.
Our grader will grade the paper copy of your project, writing comments
that indicate any issues with she or he finds with it.
A fully functional electronic copy of your project (including test classes),
in a folder named
(replacing yourUserName with your actual user-name).
A hard copy of this
attached to a hard copy of a
in which you list the files of your project (.h, .cpp, and .txt),
show that they compile and link correctly, and show that the run and
solve the problem completely and correctly.
This page maintained by