Basic tests of the linked list:

• Create an RMQList. Perform various combinations of insertions, updates, and removals; check that the list remains correct and that elements are ordered by key value.
• Check edge cases such as updating or removing the first or last entry.
• Check that utility functions like size() and empty() return the correct values; check that they are both right for an empty list; check that they are correct through a sequence of insertions, updates, and removals.
• Check that the clear() function removes all data, leaving an empty RMQList.
• Do the usual tests for the copy constructor and assignment operator: check that they make a copy of the right-hand side, that it is a deep copy, and that they work correctly when the right-hand side is empty.
• Check that insert(), update(), and remove() return the correct boolean value.
• Check that your list works with different template values (not just RMQList<int, int>).

Tests of the query() function:

• Create an RMQList; insert a bunch of data; perform queries and compare the results to a “brute force” computation of the minimum. See the sample driver for an example.
• Create an RMQList; perform some queries; do some insertions, updates, or removals; do some more queries and check that they are correct.
• Test that query() works correctly on an object created with the copy constructor or assignment operator.
• Check that your RMQ implementation is not too slow. Using the dynamic programming approach, you should be able to build the tables for a 10,000-element list and perform 1,000 random queries in a few seconds on GL. Using block decomposition, you should be able to build the table for a 1,000,000-element list and perform 1,000 random queries in a few seconds on GL.

Tests of exceptions:

• Check that query() throws invalid_argument if either key is invalid.
• Check that query() throws range_error if it is called on an empty list.

Memory leaks and errors:

• Run your test program in valgrind; check that there are no memory leaks or errors.
  Note: If valgrind finds memory errors, compile your code with the -g option to enable debugging support and then re-run valgrind with the -s and --track-origins=yes options. valgrind will show you the lines numbers where the errors are detected and can usually tell you which line is causing the error.