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!
