Python+Ubuntu+TDD

A couple of weeks ago I tried to record my desktop using gtk-recordmydesktop. It was simpler than I had imagined, so I went ahead and tried uploading the resulting .ogv file to Youtube. To my surprise Youtube swallowed the file without any fuzz – no need to resize or convert the video at all. Joy happy joy 🙂

I was a bit enthusiastic by then, so I thought ”can’t I solve some problem using my pyTDDmon tool and show it to others?”. So I picked a simple problem from the TDD-Problems site and went on.

Below you can watch the result. The first three parts were recorded the same night, with the comments added a few days later. I recorded and commented Part 4 tonight. It uses an updated version of the pyTDDmon tool, which has a little more user-friendly text-output in the console and pyTDDmon window.

Enjoy! I recommend watching the videos either in full-screen or zoomed-in. The smallish version directly below is kind of hard on my eyes at least.

Taggar: programming, python, programmering, tdd, pytddmon, ubuntu

Annons

MVP pattern practice, part 1

At work a couple of weeks ago I was given the task to build a multi document interface text editor for the LISP programming language. It was supposed to provide syntax highlighting and bracket matching, and the usual Open/Load/Save/Close operations.

Being a TDD enthusiast, I wanted to give autotesting that graphical user inteface a try. Previously I’ve tried the Humble Dialog pattern, aswell as some home-brewn MVC mixtures in the past. Both with mixed feelings (too awkward, too hard to easily test).

Anyway, since building a syntax highlighting text editor from ground-up seemed like a bad idea when there are fine Open Source alternatives like the TextEditor component from the SharpDevelop community, I started out learning the API in a spike project first of all.

When I spike-hacked away, I continously thought ”how am I going isolate/test this?”. And when I finally got to the point where I wanted to build ”Open/Close” and those basic commands, I still had no idea how to make it work.

So I started to read up on another pattern I’d heard of, the Model View Presenter (MVP) pattern. It seemed to provide even more loosely coupled types than the previous two, giving air to unit tests. But I took a too big chew; practicing and understanding the new pattern while also working with the new component was a little too stressful at the high pace of work, so I made a pragmatic decision to practice the pattern at home first, before I started using it at work.

Here we are! And I’m going to choose a really simple GUI to practice on; it will be a ”item list pick/reorder” GUI. The user is presented with a list of text items, which can be reordered using up/down arrow buttons. Then, double clicking an item chooses that item, while clicking the cancel button picks no item. Reordering is left unaffected whether the user picks an item or cancels.

This is a schematic of the GUI dialog presented to the user:

This is the first blog post in a series detailing what I find out about the MVP pattern. If all goes well, I might extend the example to more elaborate user interface. On the technology side, I intend to use Visual C# 2008 Express Edition, and the open source NUnit test framework.

Taggar: programmering, programming, mvp, csharp, tdd, gui-testing

Lovely colors

Ahhh..

This theme has been shared with love from the blog Commonality. It’s the theme called Garden of Eden.

I like how soft it is on my eyes, fitting nicely side-by-side with my continous-testing-window to the left, and how easy parenthesis are to spot. The font is Consolas.

Tags: programming, colors, visualstudio

Testing filters

So every once in a while I stumble upon an instance of this problem:

1. I have a list of entities of type A
2. I want to filter out some of the entities, with a predicate P returning a boolean for each A-instance a in the list

I try to test the predicate by building some ”positives” and some ”negatives”. But often I get the nagging feeling either the positives or the negatives form such a huge space of possibilities, that it becomes a pain to create instances of even a small subset of the variations.

For example, if I have some base-type/interface Base and the elements of the list are subtypes of this type, S1, S2, …, SN and the filter is supposed to let through only elements of type S1 and S2 but not Sk, k>=3. Also instances of S1 and S2 have to have some certain properties fullfilling some criteria to pass. You can imagine the combinatorial explosion of instances I have to try out in the test code, even to test a subset of all possibilities.

Add to that that some of the Si subtypes have 2 or 3 constructor parameters, and we’re in the jungle.

My current approach is

”test one to three positives, and one to three negatives. Ignore the nagging feeling”.

How do you approach this example?

Taggar: programming, tdd, enhetstestning, programmering

Remote pair programming experiment

Me and a Simone, both at the Software Craftsmanship mailing list, tried out an experiment in doing remote pair programming today.

NUnit

Since both of us are comfortable with C# and NUnit committing this first infrastructure-experiment to using that combination felt the right way to go.

GMail

To do this experiment we started by having gmail chat as a base for all other communication channels. Next step was to get audio working via Skype. Both of these tools worked hassle-free.

Skype

Then we turned our attention to desktop sharing. Simone had looked up some alternatives yesterday, and we tried out Teamviewer first.

Teamviewer

Teamviewer was fast and easy to use. But sadly the free edition just ended after ten minutes.

Sharedview

So we tried the free SharedView from Microsoft. This turned out to be too slow, with mouse movements showing up after about 0.5 to 1 seconds.

We gave up on the desktop sharing idea, and focused on a second approach. In that approach we share only the source files via googlecode. Googlecode uses SVN for source code sharing, and both me and Simone used TortoiseSVN to synch the files.

Googlecode

TortoiseSVN

I added Simone to one of my already existing projects to get going fast.

Then we took turns writing unit tests and production code, committing changes as we went along.

TDD Problems

All along we kept communicating via Skype.

We choose one of the smaller problems from the TDD-problems* site, the Template Engine.

Online stopwatch

To measure time we used online-stopwatch.

One problem was that I used Visual C# Express edition, while Simone used Visual Studio professional, and there were conflicts between  .csproj/.sln file formats. We solved this issue by only doing edits in one file, so to avoid this hassle.

All in all we spent almost two hours trying these things out. It was not hassle-free, but that we didn’t expect either. It was an experiment. You can see some of the resulting code in two of the screenshots nearby.

View from my computer

Template engine class

We decided to try more another time. One idea is trying the gobby multi user editor, and maybe using python or ruby instead of C#.

* If you’d like to contribute to the TDD-problems site, please drop me or one of the other contributors a mail or leave a comment on this blog post.

Tags: programming, tdd, pairprogramming, software craftsmanship