Midterm Study Questions

My software engineering course is having a midterm on Wednesday, and in preparation, my teacher assigned each of us to write 10 possible questions, similar to those that we should see on the midterm. These questions are related to the screencasts and reading assignments we have been given so far in the semester, all of which are detailed in the course's schedule. Answers are included with the questions.

Here are my study questions:

1. What is the value of using the FizzBuzz program as a test of programming skills?
   The FizzBuzz program is not a good tool to find good programmers because by nature it is a simple program; it is best used as a tool to weed out people who can't program.
   
   
2. What are some reasons people give for not using an IDE? What are some reasons for using an IDE?
   Reasons against: They are complicated to learn how to use and slow to master - you can't just write a program in your first five minutes of using an IDE; they take longer to load on a computer. Reasons for: They provide many tools, including compiling, refactoring, debuggers, and the ability to step through code; it makes it easier to understand, correct, and improve large software systems; it makes you a more attractive job candidate; makes it easier to work on large projects.
   
   
3. What are some of the differences between IDEs and build tools?
   IDEs provide tools for code writing, incremental compiliation, and testing; and are developer-specific. Build tools provide support for compiliation, testing, packaging, and automated quality assurance; are project-specific.
   
   
4. If you are trying to use an online forum to get help on a problem, what are some steps you should take before making a post and why?
   First, search for answers in manuals, online, and in forums. You should ensure that you are posting in a forum that is related to the content and level of your question so that it is not ignored. Also, you should give as much information in your post as possible, so that answerers will not have to waste time extracting information.
   
   
5. Why does multitasking decrease overall productivity?
   Your brain becomes more focused on managing multi-tasking, than on the various activities that you are trying to focus your attention on. It also takes longer to switch between tasks.
   
   
6. Why should you not rely only on coverage reports when writing tests for a program?
   Just because something was tested once doesn't mean that it will always work. Also, other problems may exist, such as code that does not do what it was originally supposed to or coding style violations.
   
   
7. What is the main difference between white box testing and black box testing?
   White box testing looks at the inner workings of the code - it sees how input is converted to output. Black box testing only checks the input with the expected output, and often preforms functional tests.
   
   
8. When using software configuration management on a team project, what are at least two things you should do in regards to creating branches of your code?
   Branch only when necessary, including when two groups need to work on code using different policies for updates; branch as late in development as possible to minimize changes that need to be propogated between branches; branch instead of freezing a codeline.
   
   
9. What are the differences between Checkstyle, PMD, and FindBugs? What implications does this have toward your choice in automated quality assurance tools?
   Checkstyle is most useful towards checking coding standards, such as placement of whitespace and use of tabs. PMD also deals with coding standards, but will also catch issues like unreachable code or unnecessary statements. FindBugs runs the program and looks for runtime issues or ways to improve the run of the program. Both Checkstyle and PMD work with the source code itself, whereas FindBugs deals with the compiled byte code. Essentially, this means that using all three tools together is a good idea, since they each check for slightly different things.
   
   
10. What is the main idea behind copyleft? How do copyleft software, free software, and open source software differ?
    Copyleft gives everyone permission to run the program, copy the program, modify the program, and distribute modified versions. However, it does not give the persmission to add restrictions to the software. Unlike free software, where people can create a proprietary modified version, users cannot create proprietary versions of copyleft software. Open source software cannot place any restrictions on distributed versions.
    

To my fellow classmates: good luck with the studying!

Robocode Project Hosting: "You've got mail!"

As the final element to the Robocode battle-robot building project that I have been working on for the past month for my software engineering course, I utilized Google Project Hosting to make my code easily available for revision. Throughout all of the assignments, my classmates and I have run into problems accessing eachother's code, and it has been an inconvenience to make a small change to a file, re-package the file, and then upload it again. This assignment sought to solve some of these problems.

I began working on the assignment by downloading a Subversion client. Subversion (SVN) is an open-source version control system, which manages files and directories over time. It keeps track of files and directories, allowing for multiple users to edit a file system, and to make it possible to always go back to a previous version of the system. The advantage to this in terms of working on programming projects is that Subversion will allow multiple programmers to work on a set of files, while doing the work to keep all of the files for all of the programmers up to date.

I chose to download TortoiseSVN, which is a version control software for Windows. It uses subversion to manage files that can be downloaded from a repository like the one available through Google Code. After downloading and installing TortoiseSVN, I was able to use it to log in and checkout a sample project from my instructor. This process means that I downloaded the code for the project with the ability to update the files in the original repository. (On the other hand, if I had merely wanted to view the source code, I could have checked it out anonymously.) I made a small edit to the downloaded code, then comitted my change so that it would be made publicly available for future users.

After getting the hang of using TortoiseSVN, I then endeavored to create my own project on Google Code, to make the code for my Robocode robot, PacerEvader, easily available for other programmers. I also created a Google group to discuss the project. In practice, this was not particularly necessary, as my robot is more or less completed, and it was an individual project. However, I can see many advantages if a programming project was worked on by a group of programmers. This is because it would be easy for all members of the group to maintain an up-to-date file set and to distribute any changes that he or she made.

I ran into one major problem while using the Google tools to manage my project, and that was in linking my Code project with the related Group. The Google Code site has the ability to send an e-mail to a single specified e-mail address whenever a change is made to the site, and the Google Group has the ability to receive posts via e-mail. Together, they seem to match up perfectly, except that I have not yet been able to link the two together. This is due to a reported bug that exists, where Google Groups does not allow the e-mail address that Google Code uses to send e-mails (more information on the issue here). New projects have an updated, working address that is used, and I have currently filed a request for the e-mail address used by my Google Code project to be updated, but as of now (October 13 at approximately 12:30pm HST), this issue has not been resolved. I have verified the set-up of both my Google code project and my Google group, so the e-mail notifications should work once the project is updated. (10/13, 4:30pm edit: My project was updated so that it sent from a new e-mail address accepted by Google Groups. I have since verified that the Google Code project will post to the discussion group when changes are made to the code.)

Robocode Editing - Testing Tools

Writing a program that compiles is relatively easy. Writing a program that does what it is supposed to and consistently generates the expected results is a much more difficult task. Luckily, there are a variety of tools available to help programmers utilize test cases to verify results and to verify that all test cases have likely been used. In the case of my software engineering class, these tools are JUnit and EMMA.

To address the issue of efficiently implementing test cases, I used the JUnit testing framework. This involved writing a number of Java test files. Unlike the test files I have written in the past, which typically involved defining a new object, giving it simple properties, then using print statements to verify that I got what I wanted, these test files would do the checking for me. JUnit will perform the actions or calculations I want, and then compare the results to what I expect, and let the test either pass or fail, depending on the results of the comparison.

Before, I begin, if you would like to reference the files I discuss, the distribution file for my newly updated and tested version of PacerEvader can be downloaded here.

There were three basic categories of tests that I had to do for my software engineering class: acceptance, behavioral, and unit.

In the acceptance tests, I verified that my robot would be able to beat two of the sample robots at least 60% of the time. This verifies that my robot is accomplishing its overall task of winning. I found that these were the easiest tests to implement because I did not have to alter the code for PacerEvader in any way - my working robot was simply placed in a battle with the sample robot that I set. I had to do a check only at the end of the battle, when I ensured that PacerEvader was the overall winner, and that it won at least 60% of the battles.

For the behavioral tests, I verified the movement strategies that I wanted to have my robot implement; namely moving to the top of the battlefield to pace back and forth, and moving to another wall when it hit another robot. These tests were more difficult for me to implement because I had to check properties of my robot after each turn, overriding the onTurnEnded method. This was not only tedious, but I also had trouble figuring out how to use the TurnEndedEvent properties to get details on my robot, as it required calling numerous methods to actual get a Robot object with all of PacerEvader's information. Because of the difficulties I had here, I was only able to complete two of the three tests I had wanted to, so I am one test case short of the required six for my software engineering requirement.

Finally, in the unit tests, I sought to verify that my robot fired using a power proportional to the distance it was from the enemy. This, by far, presented the most problems because I could not find a way to actually access PacerEvader's methods. I had first refactored my code to place the firing power calculation in a separate method, so that the value would be easier to check. However, since I could not access PacerEvader's methods, the only work-around that I could find to somewhat verify the calculations were correct were to copy my calculateFirePower method from PacerEvader into my JUnit test file and reference it from there.

In the process of testing my robot, I actually found a flaw in my implementation of the strategies for my robot. I intended to have my robot fire with power proportional to the distance from the enemy, but I left out an expression in the equation, such that it was almost always firing at maximum power. I did not realize this while looking through my code on my own, but double-checked the calculation when my test continually failed. I made the appropriate adjustments, then ran JUnit again to confirm that the change in firing power did not throw off any of the other results, the acceptance tests in particular.

After I completed my test cases, I used EMMA to analyze the coverage that my test cases provided. For the most part, I can feel satisfied with the results, given that this was my first time designing test cases for a program. All of the tests had block coverage above 70% and line coverage over 80%, aside from my main PacerEvader.java, which is not directly run since it is not a test file. (The fact that PacerEvader was not run significantly brought down the overall coverage for the package, so I am choosing to omit the overall summary.

Overall, I feel that I can still improve my test cases to truly ensure that my robot is successfully implementing the strategy I designed for it. To do this, I will need to find an easy way to monitor my robot's scanning and firing from within JUnit, because I could not find a way to check either of these. If I can accomplish this, I will feel much more comfortable with the JUnit quality assurance. I'm not sure if I could further redesign my robot to make testing easier since I am not sure of what will be required to hit the remaining test cases that I want. Through this process, though, I did realize that testing is much easier if you design the code toward it from the beginning, rather than trying to add in testing in the middle of project development.

The distribution file for my newly updated and tested version of PacerEvader can be downloaded here.

*Minor update to distribution file to correct a spelling error in one of the Java test files. The corrected version can be found here.