All posts by Timo Tijhof

QUnit anti-patterns

I’d like to challenge the assert.ok and assert.not* methods. I think they’re a bad practice.

assert.ok

Using assert.ok() indicates one of two problems:

  • The software (or testing strategy) is unreliable. (Unsure what value to expect.)
  • The author is lazy and uses it as shortcut for a proper comparison.

The former necessitates improvement in the code being tested. The latter comes with two additional caveats:

  1. Less debug information. (No actual/expected diff). Without an expected value provided, one can’t determine what’s wrong with the value.
  2. Masking regressions. Even if the API being tested returns a proper boolean and ok is just a shortcut, the day the API breaks (e.g. returns a number, string, array, function, Promise or other object) the test will not catch it.

Common examples:

// Meh
assert.ok( bool );
assert.ok( fn );

// Better?
assert.strictEqual( bool, true );
assert.equal( typeof fn, 'function' );

assert.not

Using assert.not*() indicates one of three problems:

  • The software is unreliable. (Unsure what value to expect.)
  • The test uses an unreliable environment. (E.g. variable input data, insufficient isolation or mocking.)
  • The author is lazy and uses it as shortcut for a proper comparison.

Common example:

var index = list.indexOf( item );
// Meh
assert.notEqual( index, -1 );
// Better?
assert.equal( index, 2 );

I’ve yet to see the first use of these assert methods that wouldn’t be improved by writing it a different way. Though I admit there are limited scenarios where assert.notEqual can’t be avoided in the short-term (e.g. when the intent is to detect a difference between two unpredictable return values, e.g. Math.random()).

New: mwSnapshots

Ever since MediaWiki migrated their source control management from Subversion to Git, the tool to download nightly snapshots has been froozen.

I’ve been waiting for a chance to learn more about Git’s command-line tools, so I took this opportunity to work on a new tool where I could do just that.

The new mwSnapshots tool is monitoring all branches of the mediawiki/core.git repository. Once an hour it will fetch all the new commits added to the repository and sync the HEAD positions of all branches. Then, for branches that have changed since the previous run, it will: check them out, create a new tar archive compressed by gzip, and clean up the old one.

→ Check it out: mwSnapshots

Tools moving to Git

As part of the spring cleaning this year I want to get all my toolserver tools in source control. Right now most tools are either in SVN, or not in source control at all. The ones in SVN have a directory in my Toolserver SVN repository in https://svn.toolserver.org/svnroot/krinkle/ under trunk/[name-of-tool].

Each of those will be getting a Git repository. I will be (one-way) mirroring all of those repositories on my GitHub account.

For issue tracking I never had a central location, but I’m really liking the Issue tracker that GitHub provides for repositories. So I’ll start referring to that as the central issue tracker for tools.

As a start I’ve moved these into Git, and mirrored on GitHub:

Continue reading Tools moving to Git