Friday, October 30, 2009

Continuous Integration

Continuous integration is an interesting tool that can be very helpful while developing software. Continuous integration allows for your team to upload the latest versions of the code to a repository (in my case GoogleCode) and then have Hudson automatically build the system for you and notify you when the build is complete and if it failed or completed successfully.

My initial impression of Hudson was that it was a nice way to automatically test your system. I found that the interface was well set up and easy to use and that if continuously gave detailed information about who was currently building, what the queue to build was and information about failed and completed builds. The only downside is that if the build failed there is no information on what caused the build to fail. However, the build shouldn't fail as it is the user's responsibility to run such tests as ant -f verify.build.xml to ensure a passing build before committing the changes.

Sunday, October 18, 2009

Midterm Review Questions

Here are some questions I thought would be helpful in reviewing for the midterm:

1. What is the difference between "white box" and "black box" testing?

Black Box: Design a set of test cases to see if inputs match the desired outputs. Can also catch errors of omission. No access to source code required.
White Box: Use of coverage tools (CheckStyle, ect) to find bugs. Can catch code that has been writen.

2. Why is Subversion so helpful to software development?

Allows for multiple versions to be stored in a database.
Supports optimistic locking and all files are available for check out so that multiple users can edit the same file at one time.

3. What is the purpose of Ant?

Ant provides cross platform coverage tools that execute specific xml targets which performs a white box testing of the specified code.

4. What does the task "ant -f verify.build.xml" do?

This command runs all available tools (CheckStyle, FindBugs, JUnit, ect) as well as the build.xml target and fails the build if one of the tools fails.

5. What is emma and what is its output?

Emma outputs statistics about which lines of code were executed and which ones were skipped. Breaks down the statistics by package and source files.

6. What are the 3 prime directives?

1. The system accomplishes a useful task.
2. An external user can successfully install and use the system.
3. An external developer can successfully understand and enhance the system.

7. What is the GNU project?

It is a Linux based open source operating system which strives to function with open and non open source software.

8. What are the difference in implementation of automated and manual quality assurance?

Manual: Actual writing of tests cases with JUnit, manually reviewing source code.
Automated: Uses coverage tools (CheckStyle, PMD, ect) to run tests on code.

9. How do you download someone else's code from Google Hosting?

Under the "Source" tab on Google Hosting you have two options:
1. You are part of the project so you checkout the https:// link to be able to work on and update the code.
2. You are not part of the project so you download the http:// link in order to view and modify the code but not be able to update the actual hosted code.

10. Write the FizzBuzz program.


Saturday, October 10, 2009

Hosting and Subversion

I found that Google makes hosting open source projects extremely easy. The hardest part of this assignment was actually learning how to get TortoiseSVN to upload my files to Google hosting. However after that it was all downhill and fairly simple.

Overall Results:

I was able to complete this assignment with out omitting any steps. I found that Google's user interface was very straight forth and easy to navigate and execute desired operations. Also I liked how Google Code Hosting has all the project information on one webpage ranging from the Wiki pages to the code for the robot.

Difficulties:

I found that it was hard to use TortoiseSVN to do the initial upload of files to Google Code Hosting. After watching the screencast for the week I thought that TortoiseSVN would have a similar interface for uploading as SmartSVN. However I found that there was so such interface and I had to fool around a little with TortoiseSVN until I finally figured out how to upload the files. In order to upload in TortoiseSVN you follow the same basic steps as SmartSVN in that you create a new folder and copy and paste the files you want into it. Then in TortoiseSVN you have to select the files and folders you want to upload (or the root directory would work too I think), right click and select the TortoiseSVN option. Then you have to click "add" and select the files you would like to add to the project. After that you can right click the root directory of the project and select the "SVN Commit..." button which will then proceed to as you to log in and then will upload all of your files to Google Code Hosting.

BlackMagic Code Site:

The BlackMagic site can be found here.

Wednesday, October 7, 2009

Robotesting

Creating tests for my robot was actually quite a difficult process. I ran into various problems which all revolved around me placing the test files in the wrong directory. These were easily solved by placing the files in the correctly location.

I created 2 acceptance tests, 1 behavioral test as well as 1 unit test. For my acceptance tests I pit BlackMagic against SittingDuck and Crazy respectively. For the behavioral test I made sure that my robot's first few moves are to the middle of the battlefield. Lastly for my unit test I made sure that the targeting method for BlackMagic was correct.

At first I found the tests hard to create as I have never done Junit testing before. However as I created more tests I became more comfortable with it. Unfortunately I was not able to reach the specified 6 tests due to the design BlackMagic. Because BlackMagic moves in a random fashion it is nearly impossible to test it's movements. Also the targeting is set to fire ahead of the enemy so it is hard to confirm that my bullets will hit every time. Lastly BlackMagic is very simple and uses very few lines of code which made unit testing even harder.

Considering that BlackMagic is such a random robot I believe that my tests were adequate enough to ensure the quality of my robot as I think that my tests covered almost all the possible inputs for my unit test and I ran multiple tests to confirm that my acceptance tests passed consistently (0% failure).

As far as emma goes in my BlackMagic file I used 100% of the methods and classes, however I only used 94% of the blocks and 93% of the lines. This was due to the fact that the lines specifying what to do if a enemy got too close were never executed. As for the test files, all of them were at 100% for all categories.

If I were to redesign BlackMagic to make it easier to test, I would change its movement from random to a pattern form and also I would add in a more extensive response for when an enemy hits BlackMagic. This would allow for more methods to unit test as well as a more rounded robot.

The current distribution for BlackMagic can be found here.