Today a bunch of co-workers and me got together right after work to hone our skills, more specifically, our unit testing skills.
A couple of weeks before, I had discovered that the code coverage of PHPUnit is only at ~55%, so I thought it would be a great exercise for our after work hacking to help increase its code coverage by writing unit tests for it.

The plan was to try and write as many tests as we could for the Constraint classes PHPUnit uses to implement its assertions.
Those Constraint classes are pretty small, fairly easy to understand and not entirely covered by tests – in short, very well suited for our group, a mix of programmers having quite some experience in unit testing as well as others just having started to learn unit testing.

Well, our plan didn’t work out that way, we didn’t really succeed in writing a considerable amount of unit tests.
However, it still was a valuable experience, as it turned out the unit tests of the Constraints are a good example of how not to unit test.

So here’s what we learned (or were reminded of):

Robert C. Martin aka Uncle Bob, a programmer with decades of experience under his belt, lets us in about what he has learned in his professional life and, more importantly, how he has failed, sometimes failed miserably. The Clean Coder is an important book.

In short, the author helps you to prevent you from making the same mistakes that he committed, giving orientation in one’s quest to become a true professional, a software master.

The book covers several topics, e.g. how to say no (and yes!), how to write clean code, how to test, how to become more effective and efficient.

And while all those topics are different in content, there’s one big leitmotif:

If you want to learn Ruby and you already know another programming language, Eloquent Ruby by Russ Olsen is a book you absolutely should read. Heck, even if you do not want to learn Ruby, you might want to read it because, who knows, it might give you ideas for the programming language you currently use.

So, why do I think this way?

Recently, while starting to learn Ruby, I’ve stumbled upon the following code snippet which demonstrates how you can assert that a piece of code throws as exception in Ruby’s Test::Unit:

1
2
3
4
5
6
7
8

def test_some_important_method()
  some_obj = new SomeObj
  # Potentially large amount of code

  assert_raise InvalidArgumentException do
      some_obj.someMethod
  end
end

Check out lines 5-7 – isn’t this a really elegant and readable way of expecting an exception? Now let’s contrast this with how it’s done in PHPUnit:

At work we do code review by getting emails with the diff of every commit to our SVN repository. One day I wondered whether there was an addon for Thunderbird to get colored diffs - and sure enough, there was:

In order to keep up-to-date with what’s going on in the tech world, I read a lot of blogs, visit Hacker News regularly etc. during my lunch break for example.

Frequently, I will stumble upon seemingly interesting articles but either they’re too long to be read during the break or there’s no time left to read them.
What I used to do until a year ago was to move those articles into a bookmark folder called ‘toread’, in order to remember to read it when I would have more time. But it was always a bit of a hassle, so I was never really satisfied with that solution.

Then I discovered Read It Later.