Tag Archives: Better

Watchwords

Here are some principles I try to keep in mind.

Readability Make code easy to read: code is read more often than
written.
DRYness: Don’t Repeat Yourself Avoid redundant code and data.
YAGNIty: You Ain’t Gonna Need It Don’t write code before it’s needed.
Sloth Maximize use of existing packages and libraries. The line of code you don’t write is the line of code you never have to debug. — Steve Jobs
Explicitness Explicate everything, even when “unnecessary.” If it goes without saying, it would go better by saying it. — Tallyrand
Cleanliness Keep everything clean and consistent: run static code
analysis; resolve all issues before committing.
Failed Verdict Diagnostics Log data sufficient to diagnose a failed verdict.
Error Diagnostics Detect test errors early, fail early, log useful information.
Monitoring Trust, but verify. Monitor documentation for changes (programatically, of course).

Contracts!

From the documentation for Ruby gem Contracts:

Contracts let you clearly – even beautifully – express how your code behaves, and free you from writing tons of boilerplate, defensive code. You can think of contracts as assert on steroids.

I wrote here about getting better by reviewing the literature from time to time. The literature I specifically mentioned was one of the programming language cookbooks.

Well, recently I reviewed the Ruby Cookbook (while my car was being serviced) and saw Recipe 10.16, about Contracts. The recipe had code for a Contracts module; I was delighted to find later that since the book’s publication date [2005 — but a new edition is in work!], the Contracts idea has been made into a Ruby gem: Contracts.

You’re gonna love this!

See:

And a Very Useful Warning, Indeed

I wrote yesterday about the warnings I’ve been getting from RubyMine, and my eliminating them.

RubyMine warns when it cannot find the definition of a method. I got many of these warnings for methods that are defined dynamically, at runtime, instead of statically.

At first I thought I might leave the code as-is, because if a method really is not defined, there will be a runtime error when it’s time to call it. But then I realized that there are two important consquences: RubyMine will not be able to perform either code completion or code navigation for an ‘unfound’ method.

This is important to me, because I want someone writing test code to get as much help as possible from the tools. If RubyMine can’t do code completion for a method, the programmer will have to know outright the name (and correct spelling) of the method he wants.

That will not do. So I’ve changed my code so that RubyMine now finds the definitions, and can do both code completion and code navigation.

Thanks, RubyMine!

I Was Warned!

After 90 days in my new project, it seems certain that we’re going to continue testing with Ruby, so I’ve bought an IDE, RubyMine. That gives me a debugger, which is often convenient and sometimes critical.

It also gives me static code analysis (RubyMine calls it code inspection), which is the equivalent of compiler warnings. Steve McConnell is very large with compiler warnings, as am I. In a few hour, I’ve reduced the number of warnings to zero, which is where I want it to remain. If there are a lot of unexamined warnings, something important may be hiding therein. (Actually, there was a warning about a case statement that had no else clause. I’m usually scrupulous about that, because is absence can cause downstream symptoms that are difficult to diagnose later on.)

Now my code is warning-free!

Getting Better

One way to get better is to learn a new language.

I’m beginning Windows PowerShell. I have the Windows PowerShell Cookbook from Amazon. (I always like a cookbook.)

I’m going to love never again using cmd.exe, which I’ve always hated. I’ve sometimes used Cygwin instead, but this PowerShell is positively wired into Windows.

(Yes, yes, I know I’m late to the PowerShell party, but I haven’t really needed it up to now.)

Getting Better

I’ve written about getting to be a better tester. Just this week, I’ve had occasion to consider this for myself.

Most of my work is about coding tests. But now I’ll be helping to implement some of the test harness: how the tests will run concurrently on multiple machines, and how the results will be gathered and reported.

This work is on Windows, and so an obvious need is for batch files to control the testing and reporting. I’ve never liked Windows’ cmd.exe, which I find to be clunky — difficult to write as well as difficult to read.

So. I’ll be looking into doing this work with Windows PowerShell. Friday I received from Amazon.com my new copy of Windows PowerShell Cookbook.

I’ve chosen the cookbook over other language documentation because I want to get to work quickly. This will give me a small footprint in this new (to me) language, and I can build on it later.

After completing this work, I’ll know some things about Windows PowerShell, and so I’ll be a better tester!

Getting Better

When I take on a non-trivial testing task, my employer should get three things:

  • A test result.
  • A reusable test artifact.
  • A better tester.

So when I approach a new task, I ask myself:

  • How can I shape this work so it makes me better?
  • What new skills will I acquire? (And retain!)
  • What new knowledge?

(Hint: If I can’t think of anything else, I try to learn — really learn — two or three new keyboard shortcuts. I look for what mouse moves I’m repeating, and replace them with shortcuts I look up on the web.)

Getting Better

Exploratory-testing evangelist Jon Bach once told me this:

  • Only one tester in ten that he’s interviewed claims to do anything at all toward professional improvement.

One way to become a better tester is to write.

Writing is the occasion for a serious review of your thinking. When you write, you learn — even if no one reads what you’ve written.

I’ve recently been documenting the architecture of the Coded UI Test apparatus I’m building. In doing so, I’ve found several refinements that were easy to implement, and were definite improvements.

Long years ago, a friend and I started making notes toward a book about debugging software (there were no good debugging books then). It changed the way we wrote code. Among other things, we did far more “defensive” coding.

Writing posts for this blog also clarifies my thinking. As a bonus, readers may have something helpful to contribute. (See here).