JUnit Lab

Introduction
The JUnit Lab exercise had us working with JUnit but more importantly understanding how testing is not bulletproof. The assignment also had the class working in pairs, offering more experience with pair programming, I was partnered with Tyler Wolff.

The Distribution
Stack-JUnit-Lab-Arakaki

The Task
For the main portion of the assignment Tyler and I needed to add a bug to the stack implementation from the Testing assignment. The bug had to be added in such a way that the coverage was still at one hundred percent. We also had to write an additional JUnit test case that exposed the bug and failed, but the coverage had to remain at one hundred percent.
Tyler and I added a bug to the getTop method in the ClearStack class. The original getTop method returns the top of the stack. In the modified method, getTop returns a pop of the stack. Returning a pop of a stack can cause issues with data retrieval especially when the intent was to peek at what is on top of the stack not retrieve the item at the top.







Once Tyler and I figured out a bug to introduce that maintained full coverage. We came up with up a test that calls getTop twice which returned an expected failure.



In both cases where JUnit implemented and ignored the bug test, Emma returned one hundred percent coverage. Here I thought Emma would have returned less than full coverage. But it seems Emma only checks if the method is being invoked.

The other part of the task was pair programming and team problem solving. I am always apprehensive about coding with another person. Because I am never sure if the other person can operate in a professional manner. Also, I question my abilities. Can I hold up my end of the bargain? But there was no problem with this assignment I had worked with Tyler in a previous in class lab and I found that we were an efficient team. Tyler and I clearly communicated our insights to each other so that we were able to finish much of the exercise in class.

My Thoughts
After meeting the requirements of the assignment I had come to realization that certain testing tools are not bulletproof. An innocent mistake like returning a pop instead of top can lead to horrible consequences. If a lazy developer sees that Emma is returning full coverage they could misinterpret that to mean that code is fine and is ready for deployment. Also, with JUnit, if that additional test had not been implemented no one would have caught the returning of pop bug in getTop. JUnit would have green lined the test and allowed the code to move onto the next stage of development.

Conclusion
Really the lesson here is to keep track of all changes to the code. A small adjustment can lead to big mistakes which is costly in time and money. Again code testing tools are not bulletproof, bugs can crawl through and wreak havoc. So a programmer needs to be vigilant and not be fooled by one hundred percent coverage. Because as Tyler and I just proved, full coverage plus a passing JUnit test does not mean error free code!

Testing

Introduction
For the Testing assignment, we needed to make improvements to the Stack implementation. The goal of this exercise was get to acquainted with Emma and JUnit. The task also had the class making minor adjustments to test cases and programming as a team. For this assignment I reached out through the class Google-group to search for a programming partner and John Ancheta was available to do some code fixing.

The Distribution
stack-arakaki

Working with Emma
This was my first time working with Emma and found it to be a nifty tool. I appreciate the application is letting me know which parts of the program are being neglected. However, the stack implementation contains four to five methods which seems rather trivial for a program like Emma. It would be interesting to see when a Java application has two hundred plus methods. I think when an application has so many moving parts you need Emma to check which method is being utilized.

Working with JUnit
As I have said in past blogs I do have limited experience with JUnit. So it did not take long for me to bang out a few test cases. I think I was able to help John with some of the JUnit method calls. I am a big fan of JUnit, I find writing test cases for an application only strengthens my understanding of how the tested program works. If I need to maintain the application over time I already know the program works and can quickly make the necessary adjustments. The difficulty with JUnit is trying to come up with what kind of tests should be implemented. In the past I was taught, test any method that is longer than one line and with the stack project there were several methods that more than one line of code. I know that this is only an introduction to JUnit I expect we will be writing more useful test cases in the coming future.

Pair Programming
After much thought I have come to realization that with pair programming the tasks seem to take less time to complete. John and I were able to reach 100 percent coverage in an hour. In the interest of time I suggested that we code at the same time. We perused Emma searching for which methods were not being invoked, after finding the necessary information we divvied up the tasks. From my point of view John and I worked well together if either one of us encountered a problem we discussed the issue and suggested a solution, which is how all pair programming sessions should operate.

My thoughts
For the Testing assignment I found pair programming an enjoyable experience. Although I suspect that not all coding partners are going to be like John. As for what I was feeling throughout this assignment, I felt a little fear when going through specifications for the exercise. The apprehension stemmed from my inexperience with Emma and the fear of not being able to recall JUnit code. But as I sat down and started working on the assignment the fear went away, found myself enjoying the activity of checking and fixing the stack implementation.

Conclusion
A programmer should never put all of their faith into programs like Emma. Clean and robust code is what we should all strive after but humans do make mistakes so it is to our advantage that we have development tools like Emma and JUnit. Thus far all of the assignments have been real treats to work with as I learn something new with each exercise. The Testing task exposed John and I to pair programming an area of software development that must be learned because as future programmers we need to start learning how to work within a team.

Stack Overflow

For extra credit Professor Johnson pointed the class to a website called StackOverflow. The StackOverflow website appears to be gathering place for programmers of all types: OOP, scripting, database, etc. The purpose of StackOverflow seems to be a help desk of sorts where coding questions get asked and answered.

As someone who is striving to someday be a professional programmer StackOverflow seems a little intimidating. There are coders asking questions for which I have no answer because I lack the background and expertise. However, I was able to come up with a question that has been bugging me since ICS 211. Basically, I wanted to know how to improve my design skill i.e., I am tired of programming from the hip, how can I be a better programmer? Within hours of posting the question I received eight answers from people who I assume are professional programmers. The replies were pretty much in the same vein think before coding, understand the specifications, experience helps, etc. Not that I think the answers were lame and did not get anything out of the post. The responses were similar but each reply shared a pearl of wisdom which I hope to apply in the near future.

After searching for question which I thought I could suitably answer. I found myself thinking should I reply to the question? Because from what I gathered all of the answers were from industry folk who have done some serious coding. My biggest project to date was a pseudo database from ICS 311. So I felt like a little kid amongst the grown ups. But I figure what is the harm in throwing in my answer? Hopefully, I will not get flamed for such a pitiful response.

By the way my question on design improvement received five votes which promoted me to scholar, whatever that means.

automated QA vs. manual QA

Introduction
For this assignment the class revisited their code from CodeRuler and implemented Ant, Checkstyle, Findbugs, JUnit, and PMD on the CodeRuler program. The goal of the exercise was to get an understanding of human versus machine quality assurance.

The task
I was partnered with Tyler Wolff and he was able to work on his stack while I got to work on MyRuler.java. After getting a feel for invoking the various builds with Checkstyle, Findbugs, JUnit, and PMD in the stack assignment. Performing quality assurance on MyRuler.java went a lot smoother than checking the stack assignment. After invoking the tools on MyRuler.java it was discovered that the creators of CodeRuler did not follow established coding conventions. Checkstyle returned numerous tab errors from the classes built by the CodeRuler makers. Regarding MyRuler.java, Checkstyle returned six errors which ranged from a missing period in Javadocs to using an asterisk in import statements. PMD returned fours errors that range from changing to an arrayList to labeling the switch statement. Findbugs did not find errors in MyRuler.java.

In this assignment the comparison of human error checking to machine error checking revealed how the two look at code. First, the computer will not consider the overall strategy of MyRuler.java, it could care less about how the knights attack the peasants first. When quality assurance tools run through the code. The only bits and pieces the tools care about are how the curly braces being in the right place and do the Javadocs have periods at the end of the sentence. When a human looks at the code they do care about the knights attacking peasants and strategy implementation. A human also cares about the curly brace being in the right place, because such nuances goes to readability. If a human cannot read the code how can they maintain the application? But when it comes to a co-worker or classmate examining code that spans over a thousand lines they might miss that @return statement. Having both a human and machine performing quality assurance on a program can only lead to readable-functional applications. The human can catch strategy flaws while the computer will catch style and coding defects.

Conclusion
A person is really good at catching overall design deficiencies however, they are mediocre at best when it comes to picking out coding errors i.e., bugs, class usage, improper declarations, etc. Machines are better at finding improper declarations and making suggestions as to how something should be declared.

Stack

Introduction
The stack assignment had the class implementing various quality assurance tools for software engineering in preparation for future assignments and beyond. Personally, the exercise had me working with environment variables in UNIX and writing a batch file, two things I have never done before so I would say this was a challenging exercise.

The Code
stack-arakaki

Task 1
Downloading Ant, Checkstyle, Findbugs, JUnit, and PMD was the easy part of task one. Setting the environment variables for all of the tools was a time consuming process because it was my first time at setting the environment variables in bash. What took a lot of time was from searching the web on how to set the path and implement the batch file. Although the experience of writing the path on bash was valuable I think I messed up the path for X11 (yes, I have a Mac) because I cannot start Open Office on my machine. The next step of task one, the moment of truth to see if I set the environment variables correctly. Invoking all of the tools on a stack filled with several errors. It was quite fulfilling, after spending several hours tinkering with the batch file, to see the correct output from the various tools.

Task 2
The second part of the assignment was less difficult compared to task one which involved copying and renaming stack. Also, a repeating of the invocation from task one using Ant, Checkstyle, Findbugs, JUnit, and PMD.

Task 3
Part three of the assignment was the most enjoyable, witnessing the tools in action and making the necessary adjustments to the code. I found PMD and JUnit the most powerful of the four tools in this task. PMD, was especially useful at making suggestions to which methods or classes would work better in the application. No java programmer can write effective code without JUnit. Authoring a proper and complete unit test will save a programmer many hours of grief of having to hunt down buggy code. Checkstyle and findbugs are decent tools that helps with the coding process but were not as powerful PMD or JUnit.

Conclusion
I really enjoyed this assignment, I learned how to write a batch file and make changes to the enviroment variable in bash, something I found valuable. I gained knowledge with five new coding assurance tools Ant, Checkstyle, Findbugs, JUnit, and PMD. By applying the five applications I was able to fix a stack implementation that filled was with errors and coding standard violations. So the stack exercise was beneficial and a good learning experience.

CoderRuler Review

Introduction
The CodeRuler review assignment give us an opportunity to analyze code, from the CodeRuler assignment that was written by other students in the class. The review also, exposes the class to detecting and understanding violations of the course's coding conventions.

Team Reviewed and Link to their code
du-okada-ancheta

Links to their blogs
John Ancheta
Anthony Du
Creighton Okada

About du-okada-ancheta's code
The du-okada-ancheta's code is well organized despite having three different authors. The method structure within the MyRuler class is laid out in a systematic way. The way methods are lined up it seems to follow du-okada-ancheta's strategy of having enemy knights chase runaway peasants. The methods appear to perform each task efficiently as possible. I especially like the knight protecting the castle, a nice addition to the assignment, very cool.

JavaDocs
The team of du-okada-ancheta's MyRuler.java lacked a simple statement that summarizes the code's operations. However, the team did provide bullet points for what each object is suppose to do as the program runs. Several methods lacked information on parameters and return type.

The Code
Overall, the coding was well done but there were some conventions that were missed. The instance variables should have a new line separating each declaration. Also, '}' should have its own line where some conditional statements had an 'else/ else if' preceding a '}'. There were some naming convention errors, some variables lacked appropriate titles, instance variables and methods calls were missing 'this'. Other than the issues with naming and coding conventions, the code was readable and easy to follow.

Findings

File	Lines	Violation	Comments
MyRuler.java	183,185,210,*	EJS-5	Indent nested code, each '}' should have its own line.
MyRuler.java	230,356,358,*	EJS-7	White space, new line after each new instance variable.
MyRuler.java	105,136,137,*	EJS-9	Variables need a meaningful name.
MyRuler.java	139,141,144,*	EJS-29	Need to add 'this' before calling instance variables and methods
MyRuler.java	7	EJS-41	Need a summary to describe the application in JavaDocs.
MyRuler.java	99	EJS-46	Need version number and date in class comments in JavaDocs.
MyRuler.java	200,201,284,*	EJS-54	Need comments for parameters in JavaDocs.
MyRuler.java	353,564,766	EJS-46	Author's name in class comments only.

Conclusion
Aside from the naming and format conventions, the code of du-okada-ancheta's was well written. The team of du-okada-ancheta had a decent strategy which has them beating the toughest pre-made opponents in the game. After looking at du-okada-ancheta's MyRuler.java I wish I could re-code and have my methods do a better job at conquering the opponent.

The CodeRuler review was a decent task which made me realize some of the coding and strategic errors I made while putting together my team's version of MyRuler.java. So for the next coding assignment I will do a better job at implementing error free code.

Lessons learned from Code Ruler

The members of the group who implemented the code. Erin Kim and Daniel Arakaki, Erin tackled the peasants while Daniel handled the knights. Erin did a fine job with coding the movement of the pawns. A link to the copy of the code. http://www2.hawaii.edu/~danielma/ics413/dan.m.arakaki-erinjuneilkim.zip Results

Team	1	2	3
dan.m.arakaki-erinjuneilkim vs Migrate Ruler	508 - 14	582 - 16	390 - 4
dan.m.arakaki-erinjuneilkim vs Gang Up Ruler	135 - 436	140 - 433	182 - 399
dan.m.arakaki-erinjuneilkim vs Split Up Ruler	120 - 405	136 - 392	116 - 417

What did you learn about Eclipse I have been using Eclipse since ICS 211, so I already understand how powerful an IDE Eclipse is for developing Java applications. For ICS 413, I installed the latest version of Eclipse for Mac and found the editor to be no different than the version I used on my PC. I noticed there is a plugin called Subclipse which is a tool for souce code control. When I have the time I will implement Subclipse so I can get a handle on the changes I make to my code. With code control I will not have to worry about overwriting a version that I did not mean to change. What did you learn about CodeRuler I found CodeRuler to be a nice warm up for the semester. I wish we had more time so I can have my code defeat some of tougher opponents in the game. CodeRuler did open my eyes, made me realize that I have much to learn about Java and programming in general. What did you learn about Java For CodeRuler, I relied on the material that I was familiar with and did not venture very far into new territory. Java has an expansive library and I did not take advantage of the tools that were available. The reason why I did not implement things like Collections and List was that I found it easier to work a simple array to deal with the knights, peasants, castles, etc. Taking the path of least resistance is a habit that I need to break if I want to become a stronger developer. Also, I am already familiar with javadocs after having to properly document code in Mike Paulding's ICS 211 course. Mike would have the class write javadocs in the appropriate format or else major points were taken off. What did you learn about working with another person. In a professional setting you do not get to choose your co-workers and in the case of the CodeRuler exercise my first partner was chosen for me. I will not point out my first collabrator, Professor Johnson knows who this person is, I found their attitude towards the CodeRuler assignment unprofessional. I emailed this classmate after going over the assignment, finally got a response from this person after a week. Thankfully, Professor Johnson assigned a new teammate, Erin, and we were able to crank out some code. Erin was professional, communicated well, and delivered the code as promised. I wish I could have done a better job with the knights so I could match what Erin did with the peasants. Conclusion CodeRuler is a great exercise the application got us thinking about Java again and it was nice to have some fun with an application. I suspect that the next coding assignment will not be as much fun but I am still looking forward to challenge.