Date: 2008-09-20 21:29:00
test driven development

As I've been working on shaback, I've been wanting a faster way of doing testing. Since shaback uses the Amazon S3 service, it takes a certain minimum amount of time (due to latency) to do any operation, and it adds up quickly for lots of tests.

So, my solution is to implement a local server that acts like S3 for testing purposes. I found out about Park Place, but I'd like a solution in Python that doesn't require any nonstandard dependencies. Since this server is going to be part of a testing framework itself, a lightweight solution is desireable.

I thought this project would be a good one on which to practice TDD. So I set up a unit test framework using Python's unittest, and I've been doing strictly test-first development (that is, don't write code until you have a failing test). I've been editing the server code and test code side-by-side in my editor:

This is a bit different than the way I normally develop software, but I think it's good practice to try different methods. So far it's going well.

I've been idly playing with that concept, too. Writing it in C because I'm a masochist, and planning to store the files in a SQLite database.

Haven't got much more than a basic framework yet. When I code, I tend to get the UI portion done first, then hang functional code off that.
Which concept, an S3 server? Since you mentioned storing files, that seems most likely. :)
TDD seemed very effective and cool for me (back in the days when I actually programmed!...) The main problem is the psychological issue of overcoming the seemingly universal impulse to code first and test later (or never, more likely) - a seemingly insurmountable hurdle for most programmers, unfortunately!
Yes, I fondly remember the triangle classification problem! Actually, now that I reread the report I recall that wasn't actually done using TDD (or at least I didn't).
I finally got sick and tired of testing database code manually at work and wrote a crappy framework. It's based on capturing the output of an SQL script and diffing it against an expected output (after doing a little sanitization via sed). It's not easy to edit tests, but it's better than nothing.

You have any handy vimrc magic for opening both test and code files at the same time? Especially if they'd work with multiple source and test files open at once? :)
That sounds a lot like the doctest Python module.

The screenshot above was done using the ^W^V command to split a window vertically. By splitting windows in arbitrary combinations, you can create some pretty crazy window layouts. :)
Greg Hewgill <>