Over the last few days I read articles about git commits and commit messages here, here and here. I don’t know if the article are new or years old, but I started to reflect on my usage of git and how I create my commit messages. First of all, there are two differences I make: personal repositories that only I work on and that I won’t share with anyone else (although they might be public on github) and professional repositories that I share with others or where I work together with a team.

Today I wanted to add ReCAPTCHA to one of my web applications built with NodeJS. A quick look on my heroku dashboard showed that the application wasn’t even running anymore, and a quick search through the logs showed that I was running into a quota of the connected Redis to go instance. Before doing any real work I’d have to upgrade the underlying stack, and searching for recaptcha clients for NodeJS did not bring up anything useful for me.

Today I wanted to finally clean up several backup copies of my music. Over the years I copied the files from device to device, moving through multiple generations of computers. I put the music into a Jungledisk backup, uploaded them to Amazon S3, copied them to my Drobo or just moved them from one harddisk to another, bigger harddisk. I even switched from Linux, to MacOS X, to Windows and am on a Debian machine once again.

In this blog post I want to describe how I use JMockIt not only for stubs and mocks, but for easy generation of code coverage reports while developing. JMockIt is my favorite tool for unit testing, because of it’s ease of use and the many options you get out of this framework. Only recently I decided to try the code coverage report that comes with JMockIt. I was searching for an easy way to monitor my test coverage while continuing development.