"Javing" is the present continuous form of "to program in Java".
Here you will find: code snippets, examples, tips, tricks, tutorials, best practices, miscellaneous and much more.
Enjoy your Javing!

Sunday, March 3, 2013

The legacy code that whispered to the developer

I was practicing my legacy code refactoring skills a bit this weekend (Highly on demand in the industry lately hehe.. ;) ) when I came across this fascinating line of code:

System.out.println("Process complete!!!");

My first thought was: "Whatever, just another silly console output nobody cares about!"
As usual, I run my eCobertura code coverage plugin to check how I was getting on with the level of coverage.
That line was red, it didn't bother me much so I continued with the rest of my testing and I said to myself, "I will come back to it latter...".

I was almost done when my torrent software notified me that a movie just finished downloading.
Also I started to feel hungry... I wanted to go make lunch and enjoy the movie. "Let's continue with the practice another day..." I said to myself.

After making a sandwitch I came back to my laptop with the intention of watching the movie, but my eclipse IDE was still open. And that line that eCobertura painted red, was still there looking at me:

Suddenly it started talking to me and we had a very interesting conversation:

Line 43(In a thretening tone):"Psss!... hey you!..."Djordje: "Are you talking to me?"Line 43: "Do you see somebody else in the room? Yes, i am talking to you" Djordje: "Who do you think you are taliking to like that?"Line 43: "I am a piece of untested code in your software. If you are adding code coverage I also have the right to get some."Djordje: "Why should I unit test you? You are just a piece of old legacy nobody cares about"Line 43: "You are such a dumb ass, you don't get it!"Djordje: "Get what? Leave me alone I want to enjoy my sandwitch and watch my pirate movie. Don't make an scene because I will close the IDE and I will not practice with this program never again"Line 43: "Ok, ok... take it easy! I just want to help you. Please, let's make a deal."Djordje: "What deal?"Line 43: "Just spend 5 more minutes trying to unit test me and I will teach you something important."Djordje: "Fine, just 5 minutes. This better be good, because I am very hungry"

Poor Line 43, probably it just wanted to talk to somebody. What can I learn about TDD from such a simple line of code? Anyway I decided to make it's wish come true and paint it green with eCobertura. This is what I did:

Basically what I did was just asserting that the console output is the same that what the println() command has in its argument. The process() method is where Line 43 was, so its content will go to the console when statistics.process() gets executed. At the end the method @After will restore the console output to the original stream that was previously saved.

Djordje: "I painted you green. Are you happy now?"Line 43: "Thank you very much!....Thanks, thanks.... I am so happy now other lines of code will not look me over the shoulder or whisper to each other. They use to say _There is Line 43, did you know that the developer who created it was drunk... I can now walk onto the compiler with my head up..."

Djordje: "Whatever!, You are green, please just be quiet. Are you leaving me alone now?..."Line 43: "Yes I will leave you alone, bye bye..."

Djordje:"Hey wait a second!... You told me that you would tell me something important if i get you green. What is it?"Line 43: "Sorry I almost forgot."Djordje: "Spit it out!"Line 43:"Many times when working in legacy software, developers use the so called _poor man technique. They fill the code with print commands to see the contents of the objects, the problem is that they often forget to remove them. But other times there are other print commands that are valid and really are meant to be there. In occasions, it is hard to distinguish what should be tested and what should not be. The rule is: If your application outputs valid information to the console and this is the only way you can test it, then it is correct to do it. But if you can avoid testing the console or other UI's by testing some related methods(sometimes in controllers), then you don't need to test the UI's. Remember that UI's, databases, frameworks and others... should be considered just addons, to our business layer(which at the end of the day is what provides the real business value)." Djordje: "Aaaaghhh... I hate you!"Line 43: "But why?"

Contact me

Name

Email
*

Message
*

About javing

I want to welcome you to my blog.My name is Djordje Popovic, I am a Software Craftsman and an enthusiast of the java programming language.

In 2011 I decided to create javing just as a way to keep track of my studies on the java programming language and also provide support to other fellow students. This blog has being here since the beginning of my career as a programmer. Fell free to make comments or critics to my entries, ill be happy to read them and answer to you.