On 2012-12-08, I attended the Pittsburgh Global Day of Code Retreat facilitated by Joe Kramer and Jim Hurne. As usual, I had a great time, and got to meet new people from the Pittsburgh tech scene. It’s always good for me to remember that there are non-Ruby developers out there! I even started the day off by doing the Game of Life in C#.

One of the more contentious constraints of the day was “no return values”. I feel like I was the only one in the room that liked this constraint at all! As such, I wanted to finish it up to see what my final code and observations would look like.

If you combine refactoring and making a change to your code into the same commit, you are going to have a bad time.

Running your tests in a random order is a good idea to help shake out implicit dependencies between tests. Running your tests in a deterministic random order is even better.

At work, I am still working on finding and squashing fun test failures. In this case, “fun” means tests that have an intermittent failure rate of 5% (or less!). The test issue I worked on today had to do with the “lost update” problem.

At work, we’ve been using Capybara and Selenium to test our newest web application. Many of us have used this combination before for our own projects, but it’s new territory for a work project.

Every so often, we would get this error from a specific test:

1
2

Selenium::WebDriver::Error::StaleElementReferenceError:
  Element not found in the cache - perhaps the page has changed since it was looked up

The error was intermittent, so we fell into the seductive but dangerous trap of simply rerunning our tests whenever it failed. Recently, I had a bit of time and decided to dig into it and fix it once and for all.

Have you ever seen a variable with a terrible name? This is of course a trick question; everyone has. I’d like to look at a particular variable-naming annoyance: naming the variable based on the class name.

In programming, cleaning up resources you have created is an easily-overlooked problem. In languages like C, you have to clean up everything by hand: memory, files, network sockets, etc. Languages that have a garbage collector take away the need to explicitly free memory, but you still have to manage the other resources.

For many people, JUnit is the grand-daddy of testing frameworks. Even though other testing frameworks came first, a lot of people got their start with JUnit.

People often start out testing with simple Boolean assertions, then move on substring matching, then maybe on to mocks and stubs. At some point, however, most people want to assert that their code throws a particular exception, and that’s where our story starts.

I recently did a bit of work that turned out to be a great exercise for refactoring a huge sequence of if-else statements based on strings. There are a few ugly bits left, so I’m still poking at it, but I am pleased with my progress so far.

We recently started using gerrit to perform code reviews for a legacy C codebase that I work on. I also help out on a couple of newer Java and Ruby projects that have had the benefit of having code reviews and testing infrastructure from day one.