[SOLVED] COMP2160 -Programming practices - Assignment 3

Description

In assignment 3 we’re going to apply what we’ve learned about interfaces, testing, and multi-file compilation.

Notes

• Read the entire assignment document before starting.
• Your programs must run correctly both with assertions enabled and disabled (when compiled with and without the -DNDEBUG option).
• Please be sure to follow the programming standards; not doing so will result in a loss of marks.
• Remember to complete the Honesty Declaration Checklist (you will not receive scores for your assignments until the checklist is completed).
• All submitted assignments will be scanned with automated software to monitor for academic integrity violations.
• Your assignment code must be handed in electronically. See the Submitting your assignment section below for more information.
• Late assignments are not accepted. The due date is enforced electronically.

Objectives

• Designing interfaces and building implementations.
• Multi-file compilation.
• Testing.

Question 1: Container

For question 1, you’re going to write an interface for an abstract data type (a “Container”), and you’re going to provide an implementation of that ADT with a linked list.

The interface

First, you should build an interface for the container ADT. Your container will store strings (as char*).

We’ll give you the names of the functions below, but you must write complete prototypes for your interface. Choosing the return types and parameter types is your responsibility.

Your interface should contain the minimal amount of information required for someone to use your implementation in their code.

Functions

Your interface should be implemented as container.h with the following function names:

Creating and destroying:

• createContainer (Create a new instance of the container)
• destroyContainer (Destroy the container and its contents)

Manipulation:

• insert (Insert an item into the container)
• delete (Remove the specified item from the container, only one if there are multiple)
• clear (Remove all items from the container)

Iterating and searching:

• firstItem (Start iterating over items in the container)
• nextItem (Continue iterating over items in the container)
• contains (Does the container contain this item?)
• size (how many items are in the container?)

The implementation

Once you’ve got an interface, create an implementation for the container by implementing a linked list of strings. Your implementation should define the data structure, and implement all of the functions declared as prototypes in the interface.

Your linked list implementation must apply the principles of design by contract. In particular, you should be implementing a function invariant on the linked list.

Your implementation should be implemented as container.c.

The tests

Finally, you should build an automated test suite for your container implementation.

Your test suite should be implemented in a file called main.c, and you should be sure to test all functions in the file with both general case and edge case test data.

Tests should be organized appropriately into their own functions.

Your test suite should report:

1. Progress: a statement about what the test is testing (i.e., “searching for X”)
2. Success: a statement about whether or not the test succeeded (i.e., “FAILED: expected to find X, but could not find it.” or “SUCCESS: expected to find X and found it.”)
3. Summary: a summary of the number of tests run, the number of tests passed, and the number of tests failed.

You should refer back to the Levenshtein implementation in Assignment 1 to get an idea of what a testing suite that matches this description looks like.

Building

Your solution for question 1 must include a Makefile. The grader should only have to type the command make in your directory to build your assignment.

Question 2: Black-box testing

You have been provided with an implementation of a set ADT developed by a third-party. The implementation consists of a header file set.h that defines the interface and a compiled object file with the implementation.

Your job is to verify that the third-party developer is not a terrible programmer (hint: they aren’t terrible, they’re really terrible).

You should implement a complete test suite for the set ADT and provide a report (in a Markdown-formatted README file) explaining what is broken with the implementation of the set that this really, really terrible programmer has given to you.

You should use the testing suite you built in question 1 as a basis for the testing suite you build here.

The first set

You have been provided with one implementation of the set by a competent programmer. The implementation is in a file called set.o that has been compiled on aviary (Linux). The first implementation that you’re being provided with is 100% correct – none of the functions in this file are implemented incorrectly, there are no bugs in this implementation.

The tests

Your job is to write a complete test suite for the implementation of a set.

Your test suite should be implemented in a file called main.c, and you should be sure to test all functions in the file with both general case and edge case test data. Also note that there’s a function called validateMemUse() that can be used to verify that all instances of Set that were created have been destroyed – your test suite should use this function to check for memory leaks.

Tests should be organized appropriately into their own functions.

Your test suite should report:

1. Progress: a statement about what the test is testing (i.e., “searching for X”)
2. Success: a statement about whether or not the test succeeded (i.e., “FAILED: expected to find X, but could not find it.” or “SUCCESS: expected to find X and found it.”)
3. Summary: a summary of the number of tests run, the number of tests passed, and the number of tests failed.

For the set implementation that’s provided above, all of the tests you write will pass.

The other sets

Closer to the due date, we will provide you with 5 more implementations of a set that implement the same interface. You will use the test suite that you wrote for the correct implementation of a set to determine what (if anything) is wrong with each of the set implementations that you’re provided with.

You must write a brief analysis for each file in a file called README.md. README.md should be a Markdown-formatted file (use headings!).

While the code we will provide to you is buggy, it will not crash. If you receive any error messages (segmentation fault, abort, bus error), the crash is happening in your code. When this happens, your strategy should be to re-read the comments in the set interface to better understand what each function does/requires. If you still can’t figure out why your tests are crashing, you should pull out your debugger and debug your code