麻豆约拍

Hello, my name is Jon Wilson and I'm a Developer-in-Test embedded in the Mobile 麻豆约拍 iPlayer Radio team. Our team develops the 麻豆约拍 iPlayer Radio apps for iOS and Android.

Part of my work consists of increasing the quality of the automated tests created by the team and improving their readability so that a new member to the team could quickly get up to speed with how to create and maintain our automated test suite. Our team uses based tests, using to automate user interactions with the app all tied together by a set of wrapper scripts to maintain a common set of commands across Android and iOS platforms.

The problem with having a team working on these tests is that each team member has their own idea of how the tests should be styled - some of the developers use CamelCase while those who are used to working with Ruby use snake_case, each team member has different ideas on using "do" or "{}" for multi-line blocks, etc. Add to that the fact that there's the potential for duplication as developers work on similar sections of the same tests and you can see how the test code can soon start to become messy and over-complicated.

To try and combat this, we are using two open source tools: and

Although, at first glance they appear similar (and do indeed have some overlap) they are actually aimed at two different tasks: Rubocop is geared towards adherence with the Ruby Style guide while Reek is aimed atthat are not style related.

To demonstrate what I mean by that, if we take the following code:

And run that through Reek, nothing happens. Syntactically, it is correct and, although the string is output twice, it doesn't repeat itself. Run the same code through Rubocop however and you'll see the following:

White space, encoding, line length, quotes, etc. are all issues when comparing against the Ruby Style Guide and so Rubocop is issuing Citations for the detected problems. If we use the corrections suggested by Rubocop, we'll end up with the following:

Here's what Rubocop will return when analysing the updated code:

Now if we take the following class:

Please note: I know that no one would write this code; this is purely for demonstration purposes! If you run the class through Rubocop, you'll see something like that no offences were detected. Surprising given how bad the code is, but it meets the Ruby Style Guide and so that's good enough for Rubocop. If we run Reek however:

Reek has, as you would imagine, some issues with the code - duplication, bad variable names and feature envy.

As mentioned, they do have some overlap - such as the following rules:

- Missing comments on Class / Module level

- Lines / statements in a method (Rubocop counts lines, Reek counts statements)

Here are the stats from both Reek and Rubocop when I started this work, for both the Android and iOS platforms:

Android Rubocop offences: 4190

Android Reek offences: 624

iOS Rubocop offences: 1195

iOS Reek offences: 536

And here's the latest snapshot of where we are:

Android Rubocop offences: 279

Android Reek offences: 327

iOS Rubocop offences: 536

iOS Reek offences: 247

How is this going to help us reduce future problems I hear you ask - the answer to this lies in the fact that both gems are ready to be included in your Rakefile, as seen below:

This allows the Developers to run a simple 'rake rubocop' or 'rake reek' to see if their code added any new code smells or included any violations (or citations as Rubocop calls them) of the Ruby style guide.

Jon Wilson is a Developer in test, 麻豆约拍 Future Media

听