Monthly Archives: March 2016

Badges? We don’t need no stinking badges!

In the Beginning

I am not a programmer. Well, I am but I never considered myself to be good at it. Most of the places that I worked, I was the only person creating test frameworks. I never received benefit from getting a code review of anything I wrote. I did not pair with anybody on writing any scripts, methods, or page objects. In fact, the first time I showed professionals in test automation my code, they looked embarrassed for me. When they got over the shock, they started giving suggestions that were obvious to them, but I had never learned. Hey, my code worked! Isn’t that what counted?


Well, since then I got over the big balls of mud that I was creating. I started paying more attention to the grace and simplicity of the code I saw from others. And I learned… some.

Maybe i can use more than one file for my code? Oh, I can let errors throw back to the calling function? Very interesting, I can create tests for my test tools. I can self-document these? I was learning, but I wanted more.

The Next Big Step

Within the past couple years, I have discovered a few things to help me with my programming. First, I found Rubocop (thanks Željko) which helped me to start up the style of my code. I started using standard indention, line lengths, variable names, limit the size of methods, and complexity.

Then I stumbled upon Travis-CI. I can’t remember for sure, but I think that I saw a badge on somebody’s github page. “Hey, I can use that too!” So I added that. I learned that I could run my test suite on several versions of ruby, even on JRuby. I felt that was important because I had written a tool that still used my rest client. I could add my own badge that lets everybody know my library is still good. I want people to feel confident that my builds are good so I added the badge.

Build Status

Then I saw coveralls where I learned that I my tests were missing parts of my code. It was only 10%. But it was coverable, so why not cover it? I improved my coverage to 100%. It did not drop down until… I tried to add support for JRuby9. That’s when I discovered that JRuby9 does not support coveralls yet when my coverage when down. I decided it was too early to support JRuby9. I wanted people to know that the library is tested so I added the badge.

Coverage Status

Then I hit the motherload. I was looking into a library that supported money formatting and discovered RubyMoney. Wow, they had badges for everything.

Quintuple Wow! Most of these tools are free for open-source projects, which is the only status that I would consider. Anybody can add them.

The Benefits

Adding the badges was fun, at least in the beginning. I discovered Reek this week, which is another linter for ruby. It played well with Rubocop so I added it to my project. There were different types of problems that I had to address. To support those changes, I expanded my automated tests too. When I checked in the branch, I could see how it was doing in CI. When I got negative feedback, I reworked the code. When the feedback was good, I knew I could merge the code to the master.

When I check in code changes, whether for refactoring, adding test cases, or increasing the versions of Ruby I support, I learn quickly whether my code was working still. When I learned reek didn’t support JRuby-1.7 because it’s base version of Ruby is 1.9, then I found a way to control that in both the Gemfile and Rakefile. When I tried to support JRuby9, I learned it’s not baked enough for me.

As my friend once stated, “you can never over-communicate.” Those tools are communicating to me, while the Badges are communication to anybody using my libraries.

Do We Need All Those Badges?

I also had to fool around with various configuration files to make sure the linters work working locally and cloudly (yes, I just made that up). Work is cost.

It seems like Gemnasium is going to start charging in 20 days to show my status. Money is cost.

Second thing I learned, while most of the work is in setting them up, maybe I can use some moderation in how many I use. So as long as it helps me, and as long as it’s free, I’ll use them. When I have to pay or they become more work than help, I will drop them.

Update on Book Review

When I was at ResMed, I was reviewing the book Black Box Testing in order to prepare for teaching a class to testers. Because I left ResMed in December, I will not complete the book review right now. Upon re-reading it after two decades, I find that I cherish the things I learned from it. I will continue reading it, but at a slower pace. As I do, I will submit reviews of each chapter at that time.

In the meantime, I will resume posts on investigations, experiments, and lessons that I learn in testing and testing technologies.