DT8021 Phase 1, 2015 Ed

Objectives

The objective of phase 1 is to apply the following techniques and tools in a practical case study:

• Interface design,
• Test-Driven Development,
• Functional test design, and
• Unit Testing and jUnit tool.

General Description

The first phase of this project concerns test-driven development of the kernel module of the WhatsUpGU client. This kernel module implements the basic functionalities regarding adding, deleting, editing, viewing, pushing, and pulling messages. As mentioned before, the messages are stored in the memory and persistency (using a file system or database) is not mandatory.

Before we start test-driven development, we need to fix the interface of the kernel 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 client side until it is pushed to the server side (see below). 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 pushed to the server. To do this, the sender should provide the Id of an existing message. If the message exists (and it is not yet pushed), 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 pushed to the server. 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 pushed), 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.

• ViewNew: this message will return all messages that are for this recipient and are pulled from the server but not yet viewed. After viewing the messages are marked as viewed in the data structure storing the messages.

• ViewAll: this message will return all messages that are for this recipient and are pulled from the server (regardless of whether they are viewed or not). All messages that are not viewed yet will be marked as viewed.

• Pull: pull is used to add messages that are sent to this recipient at the server. When the phone gets connected some other class contacts the server and receives all the messages added so far for this recipients from the server and adds them one by one to the data structure of messages (to be viewed later) using the pull method.

• Push: push is used to remove the messages that are sent from the client. When the phone gets connected some other class contacts the server and moves all the messages added so far by this client to from the server and adds them one by one to the server using the push method.

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 as the final outcome of this phase.

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