Pomme::TAB

It’s the first time I come across this catalog of testing pitfalls.
It’s amazing, as I can associate almost all of them to my own errors or to other’s work.

It’s very useful to put a descriptive semi-humourous name for each of these as facilitate their teaching and our ability to remember them.
This link will definitely find its way in my team’s developments standards and guidelines.

Testing Anti-Patterns:

“Somehow I missed James Carr’s TDD Anti-Patterns late last year. I’ve perpetuated almost every one at least once. If you’re new to testing, browse the list, think about each entry, and watch for it in your own code.”

(Via ONLamp.com.)

I use vim as my text editor.
Practicing TDD for creating perl applications usually imply the following workflow:

the perl code (*.pm) and the test code (*.t) open in the same terminal view where the vim window is split into two horizontal halves. That’s on my left display.
On the right display is a shell where I do run the test (prove my_test.t and its variations). The right display is also used for perldoc (and the web browser).
On the left display I obviously switch often between the two halves, writing some tests then writing the code, going back to the test code to write some more. Between each switch I always run the test.
Because of the convenience of having the test code and the application code on the same window, the ease of switching with vim and the rhythm of TDD I found TAB-switching to the other terminal window on the other screen counter productive.

I know that some people run a !prove mytest.t in command mode under vim, but that’s still too long and you have to type the name of the file.
Granted you do that only once and the other times you can just type !! to re-exec the last command.
This is screwed, if you do run other commands in the same way as the last command may not be the one you think it is anymore.

vim as a built-in command make that does different things depending on the mode. The usual set up for perl is for make to do syntax checking (perl -Wc) on the current file. This can be setup in the vim configuration file (.vimrc) in a user home directory (on UNIX) using the makeprg option.

If make could run the test for me instead of syntax checking that would be a better solution than what I described above. However I don’t want to loose the ability to syntax check as it is faster and less confusing to find stupid typos that way rather than seeing a test failing and trying to find the reason amidst the jungle of error messages.

Also, ideally, I’d like to syntax check and test run to be triggered by a press of a key rather than having to type :make.

So I’ve added these lines in my .vimrc:

map <F4> :w<cr>:set makeprg=perl\ -c\ %<cr>:make<cr>
map <F8> :w<cr>:set makeprg=prove\ -v\ %<cr>:make<cr>

After switching to the test code, pressing F8 will run the test while pressing F4 will do a syntax check.
F4 will work on any perl script, so you can syntax check both the application code and the test code.
Also you don’t have to save the file as the file will be saved before syntax check or tests is run.

You have to switch to the test code before you can press F8 to run the test.
Pressing F8 when the application code is the current file will attempt to run prove on it which will fails of course.
Ideally, in this situation, I’d like vim to find and run the corresponding test based on location/name of the application code but I don’t know how to do that.

The fact that all the main activities I do are now done on one split window, leaves the second screen for documentation (perldoc and web browser), running the whole test suite, doing other tasks, …

The benefit of the split window is also very useful when doing TDD in a Coding Dojo (or if you have only one screen) as there’s only one screen projected on a wall for the audience to see and everything is happening on this screen.

Curtis Poe has written an article on ONLamp titled “TAP vs XML”.

TAP (Test Anything Protocol) is a specification for the test report format as generated by Test::More and family in perl.

Very popular in the perl world, TAP is language agnostic and you can find test frameworks generating TAP in many languages.

There is supposedly one in python but I couldn’t find when I started my python project, so I fell back to unittests, ex-PyUnit, port of the jUnit test framework (the perl member of the xUnit family being Test::Unit).

The other thing I like about TAP is its simple and predictable format that makes its easily machine readable. That triggered a plethora of perl modules that “do things” with a TAP report.

Thanks to a module like Test::TAP::HTMLMatrix, we have been able to generate report like that:

It is based on Test::TAP::Model which I’ve seen being used to store the test reports in a SQLite database to facilitate a fined grained control of the evolution of tests (for which revision of the code they are passing, which ones are failing, if there is a pattern when a group of tests starts all to fail, …)

The ONLamp article presents TAP as opposed to XML.

TAP is good as long as you can build an ecosystem around it like we did but there’s a whole world out there where XML is deeply anchored for messaging and configuration.

It just so happens that I’ve been observing this world for a while from my perl island. What have I seen? I’ve seen tools, great tools grown up to support modern software engineering practices.

my options were:

• moaning about these tools being unfriendly to perl
• try to recreate these tools for perl projects
• subvert these tools by using them with perl

I’ve tried the first one, it was for good for me but didn’t make things moving.
The Second one has been tried too: too much code that needs maintain (and we are not paid for working on such things) and not good enough to be open sourced (because not being paid to work on such things, we rushed them).

We’ve started to look at the third option which seems to be the One.

In the case I’m interested in, it’s to fully make use of Cruise Control to support continuous integration and automated testing for my perl project.

As I am in a position where I’ve got the basic functionalities working along with some nice perl-CC integration (our HTMLMatrix test reports are now generated and archived within CC), I want to further integrate the perl testing framework to Cruise Control reporting facilities.

And this is where the TAP vs XML ends for me.

I need my TAP based perl framework to talk nicely to the Cruise Control build report.
For example, I want him to stops telling me that there’s no test run when I know that are, because CC doesn’t understand the format test output.

I don’t mind the unreadability of the xml, as XML is not for human to read.
It will be transformed by XSLT (after merging it with CC build xml log) in a human-readable form to be part of the CC build report.

I don’t mind xml generation being prone to errors by human (remember xml is not for human to use) as xml syntax can normally be validated by machines using Schemas.

I found a possible helper module on CPAN in the shape of Test::TAP::XML that needs to be investigated.

So it’s more like TAP+XML then?

For me, yes, but I just found someone who also tries to bury XML in the world of project automation

I’m mainly a perl programmer, but last week I’ve decided to explore the python language.

To keep my motivation high I’ve decided to use python for something useful to me: download every day my favorite web comic into the Pictures directory of my home directory on Mac OS X and keep it uncluttered by removing older episodes.

In the working of the project I’ve learned how in python to scrap web sites, parse XML with DOM, handling exceptions, manipulating the filesystem, doing time calculations, using regular expressions, …

Python is quite cool, and I’m planning to further improve the application.
I’m still using the default Mac OS X python, the 2.3.5 without readline
I’ll try to install a more recent version with readline support.
Python 2.5 is tempting by I don’t know if it is well supported yet by Trac, an open-source python project I’m intending to hack at some point.

I’ve added in my del.icio.us bookmarks a bunch of links that I’ve found helpful.

The other day I was discussing with software testing expert Antony Marcano about the issues encountered in introducing Test driven development in a team. Especially we were talking about resistance from the developers in introducing automated acceptance testing.

They see them as redundant: they implemented the feature and they know it works, so why do they have to write additional tests?

I reckon what has not been perceived by the developers in such situation is:
For one, a developed feature will have a life after its first release, it often has to stay part of the product for a long time. Sometimes the feature will be improved or changed as driven by clients requirements (more on that later). During all that time the client need to be sure that the feature is working. It’s obvious why the fact that the developer knows it’s working at one point in time is not enough.
Even if the feature is not being change for a long period, there may be other features that are added or changed that may break that stable feature because of interdependencies.

Secondly, what has been completely missed is the fact that an acceptance test in TDD is not really a “test” in the meaning that is commonly understood by developers.
this look like a language barriers issue (This is where Antony mentioned to me the existence of behavior driven development - or BDD). Acceptance tests are to represents the specification for a feature defined by the customer/business owner.
This specification takes the form of an automated test so that developers can code the feature against it. From a developer’s perspective it is a tangible goal to work against. Before the feature is created the test fails, when it’s done the test is passing. The acceptance tests “drive” developers effort.

This way of expressing requirements reduces the risk of ever-changing requirements as the business owner would have to update the acceptance test each time making him/her think twice when creating/changing the specification for a feature. That’s a win for the developers.
Because the business owner has written the test (maybe with help of a tester), when the test passes , they know that the feature that has been developed is what they wanted and it’s working. That’s a win for business owner.
The business owner and the developer know that at whatever stage of the life of a product, there is an automated test to assert that a particular feature is working. That’s a win for both.

On the same subject, The Register has published an excellent article last night:

Driving on the Right Side of the Code: “

Test Driven Development

“

(Via The Register.)

A couple of years ago I played with something called Camel Bones.
It is a Cocoa framework with a perl module an Xcode template.
It allow a programmer to use perl to write desktop Cocoa application for Mac OSX
It was fun, although the application built are not the fastest in the world.

I was thinking of that when I read this blog article about dynamic language to write Mac OSX desktop application. I’m particularly looking forward to Objective-C 2.0 and it’s new garbage collector.
That will make a big change, as I remember that when writing a Cocoa application with objective-C, a programmer has to handle manually memory allocation and de-allocation.

I don’t entirely agree with Scott Stevenson when he says that Obj-C 2.0 will obviate the need of using a dynamic language to write Mac OSX application: One of the reason of doing so is to give practitioner of a popular scripting language an entry point to Mac OSX programming. Also it facilitates cross-platform reusability.
If you’ve written a perl application with CLI on Solaris, you can make it a GUI application on Mac OSX by adding a GUI layer using Camel Bone or using TK to get it work on Linux. Additionally, outside Mac OSX, Obj-C hasn’t got a huge user base as perl and python have.

These bridged applications won’t be as fast and as integrated to Mac OSX as a native Objc-C application though.

Using Dynamic Scripting Languages for Mac OS X Application Development: “

There’s been a lot of interesting discussion over the last week regarding the use of dynamic scripting languages for programming desktop applications. Here are a few links that caught my eye.

“

(Via Daring Fireball.)

Grand Perspective

Originally uploaded by Rija 2.0.

Years (2 or 3?) ago, I was always struggling for space on my hard drive.
Although today I haven’t go this problem on my desktop anymore. It still an issue on the laptops. One of the tool that I found helpful at that time, was a shareware from the Omni group, called omnidisksweeper.

It calculates the space taken by files and directories and then sort the results in the familiar NeXT-ish hierarchical multi-columns view that so pervasive in Mac OS X. If you’ve your shareware you can sweep entire files and directories at the push of a button. The premise being that the system and third party software create lots of temporary huge files that are not easily visible unless you know what you’re looking for.

Grand Perspective is a software that goes further in helping you figure out where your disk space is going by constructing a two-dimensional map of the content of your hard-drive. Not only it gives you an at a glance view of the entire data usage but it’s also not ugly to see
And it’s free and open source.

I was looking for the Macintosh Human Interface Guideline on Amazon and found this gem (Newton Interface Guidelines)

Though it’s not available anymore, I’d be curious to know how valid it is when developing applications for nowadays PDAs.

Maybe one of the reason the iPhone will be closed to third parties it’s because Apple prefer to have enough experience in developing their own software, before writing an application design guide and open the handheld to external developers.

I think the environment in which the iPhone will evolve is so different than Newton’s.

Now, everything is connected, worms, malware and phishing also spread on mobile devices, on IM. PDA are now expected to be multimedia player while connectivity comes into multiple wireless flavours, all eager to drain the battery’s life (it was an excellent idea to put 2 batteries in the iPhone)

Also cautious users want snappy interface and the shortest time to completion for whatever they want to do because each second spent messing with the UI is another second of exposure to thieves in public transports.

That’s a challenge.

I think it’s a wise decision for the iPhone to starts its life closed to third parties software.

The software industry is a battle field and somebody drew a map of it.

(Source:Wired)

Buzztracker - World News - 2007-01-12

Almost a year ago, I discover a web site that track global news and represents them on a world map as circles. The larger the circle the more frequent are the news about the place. Buzz tracker also represents inter-references between places in the news articles by a link between two circles.

Using the image available on Buzztracker.org site, I’ve made a small film showing the evolution of the map over 14 days (7 of them consecutive, for the others I have been a bit lazy).

It’s interesting to see that the biggest circles are almost always the same (Iraq, big western cities) but the smaller ones are more mobile.

[QUICKTIME rtsp://streaming.pommetab.com/streaming.pommetab.com/buzztracker.mov 320 257]
images in the film are from buzztracker.org web site and the film is licenced under the same Creative Commons licence.