I’ve know Woody for a few years. He invited me to a free (yes, I said free, as in I don’t pay a dime) workshop to learn Mob Programming. After a couple of tries, I was able to attend what might be the last free workshop on February 25, 2017. It was free because Hunter Industries paid for Woody’s time, let us use their facility & equipment, provided our lunch, and volunteered their time to coordinate all the activities. Nice people.
This is my blog entry on my experience at the workshop.
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.
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.
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.
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.
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.
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.
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.
Software Quality Assurance and Test 