Assignment 2 COMPSCI 230 S2 2015

Assignment 2

COMPSCI 230 S2 2015

Submission deadline: 11.59p.m. Friday 2 Oct 2015
Total marks on this assignment: 30
This assignment counts 5% of total marks in COMPSCI 230.

Learning goals.

By completing this assignment, you get some practical experience with black box testing techniques and implementing tests using JUnit.

Asking for help.

If you are uncertain about what is required for this assignment, you should first review the lecture notes and consult the prescribed readings. You are welcome to seek assistance from others on “learning the concepts” after you have done your assigned readings for this course.

Working independently.

You are not allowed to have assistance from any other person when you are completing any part of this assignment. This must be your own work, done independently. You may gain design ideas or examples from the internet or a textbook. You should not assist another student with any part of this assign- ment. However you may help one another with setting up Eclipse projects or the JUnit environment.

English grammar and spelling.

You will not be marked down for grammatical or spelling errors in your submis- sion. However if your meaning is not readily apparent to the marker, then you will lose some marks.

Submission instructions.

Please submit electronically, using the Assignment Drop Box (https://adb.auckland.ac.nz/). Your submission will be three files:

• a single .pdf document that is your submission for Part 1 below (Test Design)

• a compressed file containing the codebase for your submission for Part 2.

• a single .pdf document explaining improvements to the codebase (Part 3).

Note: Handwritten answers for Parts 1 and 3 (if any), must be scanned for submission. Use Printers/photocopiers in computer labs to email scans to your account. Do not try this in the last minute.

1

Required resources.

  • JUnit: Using JUnit integrated in Eclipse is recommended.
  • File cs230_2015_S2_Assignment2.zip, containing the codebase to test (including a skeleton test fixture), codebase documentation and a test design document template.

    Overview

    Your best friend and coding buddy became interested in your GUI project in COMPSCI230, and decided to contribute code which permits you to add a special GUI component consisting of widgets arranged in a vertical layout (i.e., stacked on top of each other) to your application. You do not want to reject the offer of your friend to contribute code, but as you know, you cannot expect the most efficient and useful solutions and not a lot of care might be taken to avoid common bugs. Therefore, you decide to set up a test suite, i.e. a collection of implemented test cases, with the intent to reveal defects in this code. Hopefully this also teaches him/her what high quality software is about.

    The idea of your friend is to permit adding a novel GUI component (which he/she names StackWidget) to your animation app, where up to five custom widgets (your friend gave these the name ’widget element’) can be stacked on top of each other, where a new widget can be added to the top, any of the widgets can be removed, and every widget can respond to messages sent by your animation app.

    Your friend, not yet being familiar with Java collections or Swing FlowLay- outs, passes you an ad hoc implementation of the idea. The code permits adding widgets with a unique 4 digit ID number and specified size constraints for display in the GUI, deleting widgets from the widget stack based on their ID number, returning the current number of widget elements in the GUI, looking up if a widget with a specified ID is in the stack and some skeleton code for sending messages to widgets. The widget stack itself is implemented as an hoc linear datastructure based on a fixed size array. There is no code for actually painting the widgets, but you do not worry about this while your are not yet satisfied integrating your friend’s code will not spoil your nice little app.

    Test case design (10 marks)

    Study the document generated by javadoc for the StackWidget class (you should not need to look at the code, as this is black box testing). The API exposes 5 methods :

  • addWidgetElement(…..) This is a method you will test.
  • removeWidgetElement(…..) This is a method you will test.
  • processMessage(…) No tests need to be written for this method.
  • isWidgetElementInList() No need to test, but it may help you to im- plement test cases.
  • getNumWidgetElements() No need to test, but it may help you to im- plement test cases.

    2

Your task is to design a set of tests aimed at exposing defects in the methods addWidgetElement(…) and removeWidgetElement(……), taking a black- box approach. You should apply partitioning and boundary value techniques. You will be awarded 1 mark for each test you define, up to a maximum of 10 in total, as long as the tests focus on different usage aspects represent different partitions and involve boundary values. You are encouraged to design as many tests as you can think about. Extra tests won’t earn you marks for Parts 1 and 2, but will be important to help you reveal code issues in Part 3.

Test implementation (10 marks)

Import the provided codebase into Eclipse. You should implement the tests you designed in Part 1 in the ’StackWidgetTest’ class. When you run your tests, you should find that many have errors – this is good as it means your tests are successfully identifying bugs in the code. YOU SHOULD NOT CHANGE ANYTHING IN ’main’. For Part 2, it does not matter whether or not your tests succeed. You must present your tests in the same order as in your design document from Part 1 and should name each test in a way that makes it clear to the markers what you are testing. You will be awarded 1 mark for each test you implement, up to a maximum of 10, as long as the test is consistent with a test you designed in Part 1. You will NOT be awarded marks for tests that do not appear in your design document. Note that you may present each test in its own test method OR you may group tests for the same method call together. The main presentation objective for this assignment is clarity.

Addressing bugs and suggesting improvements (10 marks)

There are at least 5 defects in the StackWidget class. Your tests should help you to identify and fix these. Hopefully your tests revealed a number of defects. If not, try to think of more tests.

You will be awarded 1 mark for each defect for which you describe an accu- rate way of fixing the bug (and leave the implementation of this to your coding buddy, so he learns something).

You can get up to 3 marks for giving your friend helpful suggestions to modify the code so it is cleaner or more useful to you and other developers.

2 marks are available for pointing out flaws in the design or requirements missed out.

Following good software developer practice, please try to concurrently max- imize what you say while minimizing the number of words you write.

3