Maybe the testers in his team are doing too good of a job?

Because, you know, if testers are finding enough of “those bugs” (the ones that should be caught and controlled by unit tests and not by testers weeks after the code was originally written), maybe some developers are just not “feeling the pressure” and can’t really get that they should be writing tests for their code. If testers are very good, things just work out fine in the end… sort of. And of course, the problem here is the trailing “sort of”.
I know I’m biased, but in my view there is a ton of bugs that should never be seen by someone that is not the developer itself. Testers should deal with more complex, interesting, user-centred bugs. Non-trivial cases. Suboptimal UIs. Implementation disagreements between developers and stakeholders. That kind of thing. It’s simply a waste of time and resources that testers have to deal with silly, easy-to-avoid bugs on a daily basis. Not to mention that teams shouldn’t have to wait for days or weeks until they find basic bugs via exploratory testing. Or that a lot of those are much, much quicker to test with unit tests than having to create the whole fixture/environment for them to be found with exploratory testing.
My current conclusion is that pushing on the UI/usability side is not only good for the user, but it’s likely to produce better code as it will be, on average, more complex and will have to be better controlled by QA (code review, less ad-hoc design, …) and automated tests. Maybe developers will start hating me for that, but hopefully users will thank me.

• Software automated testing 123, an entry-level talk about software automated testing. Why you should be doing it (if you’re not already), some advice for test writing, some basic concepts and some basic examples (in Perl, but I trust it shouldn’t be too hard to follow even if you don’t know the language).
• Taming the Snake: Python unit tests, another entry-level talk, but this time about Python unit testing specifically. How to write xUnit style tests with unittest, some advice and conventions and some notes on how to use the excellent nosetests tool.
• Introduction to Debian packaging, divided in four sessions: Introduction, Packaging a simple app, Backporting software and Packaging tools.

Just a quick note about them: the slides shouldn’t be too hard to understand without me talking, but of course you’ll lose some stuff that is not written down, some twists, clarifications of what I mean exactly by different things and whatnot. In particular, the “They. don’t. make. sense. Don’t. write. them” stuff refers to tests that don’t have a reliable/controlled environment to run into. I feel really strong about them, so I wanted to dedicate a few more seconds to smashing the idea that they’re ok, hence the extra slides :-)

Enjoy them, and please send me any comments you have about them!

The functional tests failed because of some stupid change in Rails 2. Namely, it seems that now you can’t make more than one request in a single functional test method (bug?). The acceptance tests had some minor problems due to some changes I made in the interface. The rest worked without problems.

Now that everything is ported and working like a charm, it’s time to make some interesting changes. I had been wanting to use a really cool library called RemixUI, made by my former company, Fotón Sistemas Inteligentes, and these days I finally had the chance to use the latest version. RemixUI is a “web widget” library, similar to DJWidgets, MCWidgets and RemixWidgets (all of them available in the Fotón BerliOS page, but unfortunately obsolete), that makes it much easier to write validation, integration between client side and server side, interface improvements with Javascript, reusable widgets/controls, etc.

I haven’t used it that much yet, but I’m really eager to change all the forms and controls in the application to take advantage of the cool stuff offered by RemixUI. The problem now is that the RemixUI gem is not public yet, so I can’t really release the new version of Haberdasher. I’ll try to make them put the Gem somewhere public, so I can release Haberdasher, and other people can have a look at RemixUI.