Here are some principles I try to keep in mind.
||Make code easy to read: code is read more often than
|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.
||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
||Explicate everything, even when “unnecessary.” If it goes without saying, it would go better by saying it. — Tallyrand
||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.
||Detect test errors early, fail early, log useful information.
||Trust, but verify. Monitor documentation for changes (programatically, of course).
From the documentation for Ruby gem
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!
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.
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!
[I’m going to start putting up some very small Getting Betters. It’s easier to make a small change than to make a large one.]
Get better by getting faster:
- On Windows, open an instance of Windows Explorer (file browser) by pressing Windows-E (the Windows key and the E key at the same time).
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.)
One way to get better is to play for the team.
This lovely editorial remarks upon the value of teamwork — and just plain work — as exemplified by the San Antonio Spurs, over many years.
[Oops! I did not realize that this article requires a subscription. I need to get 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!
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.)
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).