Assignment title: Management


Testing and Verification (DIT085) Practical Assignment General Instructions The assignment concerns the test-driven development, integration testing, model-checking, and user-interface testing of an ​autonomous parking assistance system ​. From the testing and verification perspective, the project comprises the application of the following techniques: ● test-driven development, ● unit testing using ​ ​jUnit ​, ● gathering coverage metrics using ​EclEmma ​ (or similar tools), ● integration testing, including developing stubs using ​Mockito ​ (or similar tools), ● model checking using ​Uppaal ​, and ● UI testing using the ​Sikuli ​ tool. The assignment runs in tandem with the corresponding topics during the course and provides a hands-on experience on the topics treated throughout the course. It is a complementary assessment form to the written examination, where mainly the theoretical subjects of the course are examined. This is a group project that is to be carried out in ​groups of 4 ​. You need to have formed your groups in GUL and emailed your group structure to ​the lecturer and both instructors ( ​[email protected] ​, ​[email protected] ​, ​[email protected] ​) by ​Thursday January 26 at 17: ​00; please put '[DIT085] Group Registration' in the subject line of your email. The deliverables are to be delivered on the GUL system and discussed orally in the presence of all team members with one of the two instructors. The deliverables comprise a report and the implementation code: the report should document the major steps in each phase and code snippets (few concise examples) of how they are implemented and possibly screen shots of the results. Extensive pieces of program code should not be included in the report. The most important factors in judging the reports are: their logical structure and sufficiently clear explanation of the steps (all figures and code snippets should be accompanied with clear descriptions).The deadlines are to be respected and each phase is to be delivered both on GUL and discussed before the deadline. You may get an extension of one week for at most two phases; for that you need to send an email before the deadline to the instructors. Sending an email is sufficient for receiving the extension and you need not wait for a response to your email. As a general principle, when you find an ambiguity in the requirements, make a reasonable assumption and document it clearly in your report. After you deliver each phase, each and every member of the group should send an email with an estimate of each member's participation in that phase (in percents) and the parts of the deliverable each member has contributed to. The assignment is organized in the 3 following phases: ● Phase 1: TDD and Unit Testing, ​Deadline: February 3, 2017, 23:59 ● Phase 2: Integration Testing, ​Deadline: February 17, 2017, 23:59 ● Phase 3: Model Checking and UI Testing, ​Deadline: March 3, 2017, 23:59Phase 1: Test-Drive Development and Unit Testing 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. Description of the Unit The first phase of this project concerns test-driven development of a module that has the basic functionalities regarding an autonomous parking assistance system as follows: ● We assume that the car moving along a perfectly straight street which is 500 meters long and registers the available parking places on its right-hand side. ● To do this the car moves forward and uses two ultrasound sensors to check whether there is a free space on its right hand side. ● The measurements are combined and filtered to reliably find a free parking stretch of 5 meters. ● The car then moves to the end of the 5 meter stretch and runs a standard parallel reverse parking maneuver. To do this, first design a class with the following methods: ● MoveForward: This method moves the car 1 meter forward, queries the two infrared sensors through the isEmpty method described below and returns a data structure that contains the current position of the car, and the situation of the detected parking places up to now. The car cannot be moved forward beyond the end of the street. ● isEmpty: This method queries the two ultrasound sensors at least 5 times and filters the noise in their results and returns the distance to the nearest object in the right hand side. If one sensor is detected to continuously return very noisy output, it should be completely disregarded. You can use averaging or any other statistical method to filter the noise from the signals received from the ultrasound sensors.● MoveBackward: The same as above; only it moves the car 1 meter backwards. The car cannot be moved behind if it is already at the beginning of the street. ● Park: It moves the car to the beginning of the current 5 meter free stretch of parking place, if it is already detected or moves the car forwards towards the end of the street until such a stretch is detected. Then it performs a pre-programmed reverse parallel parking maneuver. ● UnPark: It moves the car forward (and to left) to front of the parking place, if it is parked. ● WhereIs: This method returns the current position of the car in the street as well as its situation (whether it is parked or not). In all of the movements, the car sends a signal to the actuators moving the car, but the actuators are not modeled in this phase. Likewise, all the sensor signals come from sensor classes that are not modeled in this phase. You can assume random or fixed sensor inputs in this phase. The sensor inputs (for a properly working sensor) are integers (in the range of 0 to 200) indicating the distance to the nearest object on the right. 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 Before starting any implementation, think of the data structures you need for this unit and a short description of the methods you need and what they should do. The next part of this 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 packet structure and the interfaces 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. Each line of code should be augmented with the reason why it has been added (which test case it is supposed to satisfy). Before you start each step in the implementation, implement a test-case as a jUnit test, observe how it fails, add the line(s) of code necessary to satisfy it, observe that all tests pass afterwards and comment the line(s) of code to specify why they have been added. In your report, describe in a step-wise manner how each piece of implementation has been added to fulfil a test-case. Part 3: Self- and Group-Evaluation Write a paragraph describing the parts of the deliverables you have contributed to. Also, estimate the amount of effort each and every group member has spent on the whole phase both in hours and in percentage. Note that for each group member you should report a separate pair of numbers (hours and percentage of the total work). This deliverable should be send by each group member in a separate email sent on the same day to the supervisor handling your other deliverables. Group submission will not be accepted. Your mark on each deliverable will be judged based on the quality of the deliverable, the result of the discussion, and the share of work you seem to have performed according to the self- and group evaluations.Phase 2: Integration Testing and Coverage The description of this phase will be posted here by the deadline of Phase 1. Phase 3: Model Checking and UI Testing The description of this phase will be posted here by the deadline of Phase 2.