Sunday, October 18, 2009

Midterm Study Questions

Here are some study questions for the our midterm.

Update: Added the answer to the questions

1. What are the three prime directives?
  • The system accomplishes a useful task
  • An external user can install and use the system
  • An external developer can understand and enhance the system
2. Give one example of a basic Collection class and describe it
  • Sets: no duplicates and add works differently
  • SortedSet: traverses elements in their "natural order"
  • List: Ordered collection and like an array with flexible size
3. Give three examples of our class Java Coding standards.
  • 2 space indent
  • No tabs, only spaces.
  • Left curly brace on preceding line; right curly brace on its own line
  • 100 columns of text maximum maximum
  • JavaDoc layout standards
4. What are some advantages of using Ant vs. Make.
  • Java-based
  • xml is simpler than a Makefile
  • Built in Java support and its tools
  • Easier to extend in a portable manner
5. Why do we have to run Ant once in order to import distribution files to an IDE.
  • So that Ant downloads the necessary libraries needed
6. Write a sample Ant Target code.

<target name="TestTarget"
        
description="Target that does nothing.">
</
target>


7. What are some advantages of Git over SVN.
  • Allows users to work productively even when not connected to a network
  • Makes most operations much faster since no network is involved
  • Allows participation in projects without requiring permissions from project authorities
  • Avoids relying on a single physical machine. A server disk crash is a non-event with distributed revision control
8. What is the difference between White box and Black box testing.
  • White box testing tests the implementation of the code where it accepts an input and produces the appropriate output
  • Black box testing tests the expected output given the input
9. What are the three classic CM problems and describe them.
  • Double Maintenance: prevents multiple copies of the same file and must be updated independently
  • Shared Data problem: allows two or more developers access the same file/data
  • Simultaneous Update: Must prevent clobbering when two updating the same file at the same time
10.What are some properties that defines an OSS.
  • Free Redistribution
  • Source code availability
  • Derived Works

Tuesday, October 13, 2009

Configuration Management: Subversion

In this assignment we have to practice using subversion as our centralized configuration management tool using TortoiseSVN as a subversion client and Google Code to host our source projects.
All in all I find this assignment very helpful in any group projects. Tortoise was very easy to use and install. When I first imported my source codes to Google host, I accidentally uploaded other directories such as bin, lib and build. Tortoise was easy enough to use where I just deleted my local copy and committed the changes to Google host's copy. As good as Tortoise's function are, I find it weird that I have to right click within directories to use all of its function instead of a graphical interface such as those in SmartSVN. Setting up Google host site was just as easy as using Tortoise. All tasks were completed except for adding a codesite-noreply@google.com. I posted to the appropriate forum so that they can add the link to our discussion manually.

You can check out my host site here and discussion here.
Updated WallEE.

Wednesday, October 7, 2009

Testing: It's not as easy as it sounds!

On this assignment, we have to create different test cases for our Robocode robots. These test cases are Acceptance, Behavioral, and Unit tests. Acceptance test are tests that simply checks if our robot beats one of the sample robots in a given number of rounds. Behavioral test are tests that makes sure our robot’s movement, firing, or targeting are doing what they are intended to do. Lastly, there are Unit tests which verify our robots’ method output given different inputs. The later might have to be written after our robots’ code is "refactored".

We were given a heads up on the what these test are when we described possible test cases on our partner’s robot during lab. Describing these tests was easy enough but little did I know that implementing these seemingly easy test was going to be so hard.

For my acceptance test I used SittingDuck and Corners against WallEE. As for my behavioral test, I created a test to make sure my robot turns in the right direction since WallEE is based on sample walls, it turns left towards and perpendicular to the first wall it sees. Lastly my unit test consists of testing how my robot fires a bullet with power proportional to the distance of the enemy. This was the hardest to implement because I did not have the methods that was in accessible in WallEE such as determining the distance between WallEE and its enemy. This was a great opportunity for me to modify my code in order to have a “testable” block of code, which I did but to no result. It was hard for me to “refactor” that specific code so that I can test it and at the same time preserve its original function. So I did most of the distance calculation within my test which I know is not a good idea because it does not preserve the encapsulation of my code.

I don't feel that my tests adequately ensure the quality of my robot because I only have four test cases. Two of which are acceptance and one of each behavioral and unit tests. What I would have done is to test my other movement strategy which is WallEE treading back to where the enemy was to get another shot.

After implementing the test cases for the junit, I ran Emma which is another build tool that measures and reports Java code coverage. Here are the results:
  • Class - 86%
  • Method - 88%
  • Block -84%
  • Line - 85%
From these result I learned that Emma will doesn't really look at TestBedAssert which accounts for the missing coverage. Some of the code in WallEE's class was not run, onHitRobot, since most of my test enemy is a sittingDuck robot.

All in all this assignment was hard but very rewarding. The practice we get from creating not just only any test cases but good test cases will help us write codes that are both easy to understand and easy to test.

The new distribution file of WallEE can be downloaded here.