Revision as of 15:05, 12 January 2015

Objectives

General Description

The first phase of this project concerns test-driven development of the kernel of our WhatsUpGU server. Before we start test-driven development, we need to fix the interface of the to-be-implemented module, which should provide the following functionalities:

• Add: adding a non-empty string message from a given Id (the sender's telephone number) for a given ID (the recipients telephone number); the message is supposed to be stored at the server side until it is fetched by the recipient. For simplicity, we assume that the message is stored in the memory. Upon successful addition of the message a unique positive integer as the identifier of the added message is returned; upon failure a value indicating error (0 or a negative number is returned).

• Delete: the sender of the message can delete the message before it is fetched by the recipient. To do this, the sender should provide the Id of an existing message. If the message exists (and it is not yet fetched), the message is deleted and the Id of the message (a positive integer) is returned. Otherwise 0 or a negative number indicating the reason for the error is returned.

• Replace: like in the previous item, the sender of the message can modify the message before it is fetched by the recipient. To do this, the sender should provide the Id of an existing message and a new non-empty string to replace the existing message. If the message exists (and it is not yet fetched), the message is replaced by the new string and the Id of the message (a positive integer) is returned. Otherwise 0 or a negative number indicating the reason for the error is returned.

• Fetch: when a cell-phone gets connected to the Internet, it contacts the server and fetches the messages sent to it since its last time online.

This is performed by calling the fetch method and passing the identifier of the recipient; as a result, messages are returned as a string (with an XML structure indicating messages, their Ids, and their senders.

• Fetch-complete: Once the recipient has fetched and displayed all its messages, it will signal the successful completion of the fetch operation and as a result, the messages will be removed from the server; the sender will also be signalled to mark the fetched messages at its client user interface. Fetch complete will return a positive number if it has been successful or non-positive number indicating the type of error happened.

Deliverables

There are two main deliverables for this phase: a single pdf file documenting the outcome of each and every of the following steps and a .zip file containing the source code of the software implemented in different parts.

Part 1: Interface and Test Design

The first deliverable concerns the interface and the test design of the above-specified module. For the interface, you need to specify the signature of the methods: name, input argument types, and output return type. For each interface method, you need to give its specification in the following form:

/**

  Description

  Pre-condition:

  Post-condition: 
  
  Test-cases:

*/

To design your tests, first use one of the functional testing methods (preferably: classification tree or decision table) to partition the domain of different inputs (or output) using the above-given requirements. As a general principle, when you find an ambiguity in the requirements, make a reasonable assumption and document it clearly in your report. Then define a test suite (a set of test-case) with concrete input values and expected outputs.

Your deliverables will be judged based on:

• soundness: whether the interfaces and their specifications have been correctly specified (according to the requirements), the test technique has been correctly exploited to design test cases, and
• completeness: whether all requirements have been considered and all test-cases necessary to cover them have been given.

Part 2: Test Driven Development

For each and every method, apply the principles of test-driven development to implement the interfaces in order to satisfy each and every test-case. Before you start your implementation, implement your test-cases as a jUnit test. In your report, describe in a step-wise manner how each piece of implementation has been added to fulfil a test-case.