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

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

ALT.NET [GBG]-mötet måndag kväll

Jag kom till Bishops Arms vid 19.20 måndag kväll. Jag tänkte jag skulle vara först, och invänta de andra. Tji fick jag! Magnus och Kristoffer hade redan anlänt. De hittade ett litet ”krypin” under trappan, som ett slags avsides rum. Perfekt för nördsnack!

Med varsin öl och mat på ingång satte vi igång och snackade .NET och branchen. Snart dök också Johan upp. Det blev en heltrevlig kväll som tog slut först efter tio.

Kristoffer hade med sig sin laptop och visade ett open-source-projekt han pysslar med — ska inte avslöja vilket då han fortfarande inte vill gå ut alltför ”officiellt” med det. Det verkade spännande och användbart – så mycket jag nu förstod av det. Det var webbrelaterat, och eftersom jag är en WinForms-kille nästan uteslutande (i alla fall i .NET-världen) hade jag lite svårt att hänga med. Och så hade jag fått i mig ett par öl vid tidpunkten 😉

Ett litet enhetstesttips gav jag, nämligen att man kan använda ordet ”Expect” istället för ”Assert.That” i sina NUnit-tester. Detta gör man genom att låta ens testklass ärva ifrån klassen ”AssertionHelper”:

public class SomeTests : AssertionHelper {

  [Test]

  public void Example1() {

    var result = new MySUT(1).Compute(2);

    Expect(result, Is.EqualTo(3));

  }

}

En lång och energisk diskussion vi tog upp var olika indelningar av automatiska tester. Jag sysslar än så länge uteslutande med mikro/fokus/enhetstester i samband med utvecklingsmetodiken TDD. Så för mig var det mäkta intressant att ta del av floran av verktyg som finns för .NET när det gäller automatiska tester.

Jag vill dela med mig av den ”tabell” vi ställde upp för att strukturera våra tankar (eller mina framförallt hehe).

Till att börja med sorterade vi alla termer för tester vi kom på i tre olika mer eller mindre väldefinierade kategorier. De tre kategorierna var (jag väljer ut en av termerna för att namnge kategorin så jag enkelt kan diskutera den nedan):

1. Acceptanstest. Relaterade termer: Acceptanskriterier, User stories, Customer tests, GUI-tester*.
2. End-to-end-test. Relaterade termer: GUI-tester*, integrationstest, regressionstest, systemtest, lasttest, smoketest.
3. Enhetstest. Relaterade termer: mikrotest, fokustest.

* just GUI-tester valde vi att lägga ”mittemellan” kategori 1 och 2, då de inte riktigt kändes klockrena i någondera kategorin.

Sedan valde jag ut några olika egenskaper att beskriva de tre kategorierna utifrån. Jag går igenom egenskap för egenskap nedan.

Verktyg
På denna rad i tabellen fyllde vi i alla de verktyg vi diskuterat under kvällen.
Acceptanstest: TestComplete, StoryTeller, WebAII, Watin, FitNesse, Selenium.
End-to-end-test: NUnit, MbUnit, MSTest, xUnit.
Enhetstest: NUnit, MbUnit, xUnit, MSTest, Moq, RhinoMocks, Typemock, Pex.

Före/efter
På denna rad fyllde vi i om tester inom kategorin ifråga vanligtvis kodas före eller efter produktionskod.
Acceptanstest: Efter (dock skrivs User stories och deras acceptanskriterier före, fast dessa består inte av kod utan vardagsspråk!)
End-to-end-test: Efter (eftersom de brukar vara känsliga eftersom de är långa och nära inpå systemet).
Enhetstest: Före (såklart!)

Antal
Här gjorde vi ett slags grovuppskattning om antal tester inom varje kategori för ”ett typiskt projekt”.
Acceptanstest: 100 st
End-to-end-test: 300-400 st
Enhetstest: 2000-4000 st

% av utvecklingstiden
Här försökte vi uppskatta hur tidsfördelningen i ett typiskt projekt var, alltså utvecklingstid.
Acceptanstest: 20%
End-to-end-test: 20%
Enhetstest: 60%

Sammanfattningsvis kändes det nyttigt att få ett slags ”helhetsperspektiv” över automatiserade tester. Jag är som sagt novis på Acceptanstest/end-to-end-test, och det skulle vara kul att börja testa några av verktygen på riktigt.

Ytterligare en jämförelsediskussion jag kom på idag är ”Varför?”. Alltså något slags moralisk förklaring till vilket problem en viss kategori är till för att lösa.

Kanske något att diskutera på nästa möte..?

Innan vi skildes åt kom vi fram till att vi spikar 2:a måndagen varje månad under hösten för ALT.NET-GBG-möte. Detta eftersom det passade oss alla fyra bra tidsmässigt. Runt 18.00 den 12e oktober ska du alltså boka in om du är .NET-kodare, gillar modern programvaruutveckling och en eller annan öl!

Taggar: programmering, alt.net, göteborg, tdd

Veckoutmaning: Litet spel på IPhone (2/7)

(detta är del 2 av 7 i en serie om hur jag bygger ett litet spel till IPhone på en vecka. Läs del ett som beskriver spelidén och reglerna.)

Den här dagen har blivit lite av en ”reality check” för mig. Jag började med att sätta ihop en lång lista med ”items” jag behövde för att kunna bygga spelet. Den blev längre än jag trodde, och det är lätt att bli lite missmodig.

Här är valda delar från den listan, som beskriver det jag behöver lära/bygga/designa:

• Grafik: teknik. Använda texturer eller bara trianglar? Om texturer: lär om hur läsa in bitmappar i Objective-C, implementera texturuppladdning till OpenGLES (GLES = Graphics Library Embedded Systems; en strippad version av vanliga OpenGL som används på ”små enheter” som mobiltelefoner)
• Grafik: data. Oavsett metod, måste bilderna/triangelinformation skapas.
• Ljud: teknik. Läs om hur man spelar upp ljud på IPhone., och hur man läser in samplingar i minnet/laddar upp till ljudkortet (eller hur det nu funkar på IPhone). Prototypa/implementera.
• Ljud: data. Skapa samplingar, eller hitta på nätet.
• TDD. Jag är såpass invand med TDD-tekniken att jag helst av allt vill ha vettiga enhetstestmöjligheter. Ja faktiskt har jag svårt att se hur jag skulle trivas med att utveckla någonting utan enhetstester nuförtiden.

Jag hittade en artikel som beskriver googles approach till TDD på IPhone, den har jag skummat plus en introduktion till OCTest som är ett enhetstestramverk för XCode.

Installation + första testet med OCTest blir en bra början imorgon tror jag!

Taggar: iphone, programmering, objective-c, opengl, spel

Två kollaborativa textprogram

För några veckor sedan letade jag febrilt efter något onlineprogram för att editera texter med flera användare samtidigt.

Anledningen var att jag och en kille från andra sidan världen (nåja, Italien var det iof men ändå långt från Götet!) tränat på parprogrammering+TDD tillsammans ett par gånger tidigare i vår, men lackat ur pga de stora fördröjningar den ena hela tiden utsätts för. Tekniken vi använde då var s.k. Desktop Sharing, t.ex. via Fjärrskrivbord eller VNC. Läs detta inlägg om du vill veta mera om vad vi använde för verktyg och hur det funkade.

I alla fall; jag kände ju till Google Docs sedan tidigare, som är utmärkt för att t.ex. skriva uppsats tillsammans (skolarbete/grupparbete/förening…) men det kräver att alla har så kallat google-konto. Dessutom är det ganska nedsmetat med funktioner man inte är speciellt intresserad av som programmerare.

Nåväl, jag hittade till slut ett par olika alternativ för ”kollaborativt textskrivande”. Det första är Etherpad:

Etherpad - varje användare använder viss bakgrundsfärg

Etherpad kräver ingen inloggning, och varje deltagares text färgas efter dennes val av färg. Det ger en tydlig och enkel översikt över ”vad som händer”. Det är helt klart ett attraktivt alternativ för ”remote pair programming” som är målet. Nackdelen med etherpad är att det bara stödjer så kallad syntax highlighting för språket JavaScript.

Eftersom jag kodar C#/Python/C++ mestadels, letade jag vidare. Min Italienske vän hittade följande program: Collabedit:

Collabedit - rent användargränssnitt

I Collabedit finns det stöd för färgkodning (som syntax highlighting heter på svenska) i alla de språk jag vardagligen använder, och många fler. Inte heller Collabedit kräver inloggning utan funkar rakt upp och ned.

Det som återstår för att uppfylla målet ”remote pair programming” är ett script som gör föjlande:

1. Laddar ned dokumentet från nätet (t.ex. med hjälp av wget)

2. Kör dokumentet i ”testläge” (t.ex. via någon flagga så att dokumentets tester körs)

3. Väntar på användarens knapptryckning

4. Hoppar till ett

På så sätt kan varje deltagare köra testerna vid behov. Alternativet är att byta ut (3) mot lämplig paus, t.ex. 10 sekunder, så behöver man inte ens trycka tangent för att köra om testerna. Jag kallar denna teknik ”kontinuerlig testkörning” och använder den ofta på jobbet. Det blir som en ”hjärtmonitor” på programsystemets ”hälsa”.

Det ska bli intressant att experimentera med dessa verktyg! Jag kommer att återrapportera hur det känns och funkar när jag kommit längre.

Taggar: programmering, tdd, parprogrammering, agile, remote pair programming, etherpad, collabedit

Död programkod

Hittade en gammal anteckning från att jag skrivit mitt första större dataprogram i C. Det var ett textspelsäventyr kallat Slasher (Slasher 2 för att vara noggrann – första versionen skrev jag till miniräknaren TI-80, populär på gymnasiet!). Tror programmet var c:a 5000 rader långt, förmodligen mycket längre än det behövde vara (det var också mitt första C-program!), men det intressanta är anteckningen som kommer här:

När man bygger ett program kommer man till sist fram till en punkt då programmet är så stort att det blir oöverskådligt och att lägga till nya funktioner vore ödesdigert för dess ‘överlevnad’. Slasher är det projekt som kommit närmast detta tillstånd och har faktiskt vid ett flertal tillfällen gått igenom genomgående förändringar vilket varje gång kunde resulterat i att programmet ‘dött’.

/Olof, 18 år

Denna nyckelobservation och utmaning har tagit mig mer än tio år att bestiga. Jag fann lösningen i enhetstesterna!

De ”genomgående förändringarna” jag talar om kallas ”large scale refactorings” på fackspråk. Refaktorisering tycker jag låter humbug – jag föredrar det mera svenska ordet förenkling.

Taggar: programmering, tdd, c, enhetstester

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

Enhetstester & simulering: en analogi

På senare tid har det blivit alltmer populärt med så kallad virtualisering. Det innebär att man via ett program kan köra andra operativsystem än det man har installerat på datorn. Detta sker genom så kallad mjukvaruemulering.

Det kanske låter som magi, men det är egentligen – i princip – väldigt enkelt. Ett operativsystem som kör på en dator är nämligen inget annat än en massa instruktioner (heltal) i en lång följd, och om man kan följa vad dessa instruktioner betyder, till punkt och pricka, kan man ”lura” operativsystemet att det körs på en äkta, fysisk dator. Men i verkligheten körs (”emuleras”) operativsystemet ”inuti” ett vanligt program!

Ett par populära sådana virtualiseringsprogram, för att simulera PC är VirtualBox och VirtualPC.

Ubuntu + WinXP

Till exempel har jag Ubuntu installerat på min dator hemma. Jag har installerat programmet VirtualBox i Ubuntu, och inuti detta program har jag installerat WindowsXP! På så sätt kan jag köra bägge operativsystemen samtidigt!

Nåja, detta är inte en bloggpost om virtualiseringsteknik, eller emulering som är en vanligare benämning vid simulering av lite äldre datorsystem som Commodore 64 (I love you!) eller TV-spel som Sega-16-bit (love you too!).

Låt mig bara dra en parallell till innan jag kommer till inläggets kärna!

Inom fysiken jobbar man med matematiska modeller av verkligheten. ”Matematisk” betyder bara att modellen består av ekvationer. Modellen är en förenkling av verkligheten, men man strävar såklart efter att den är tillräckligt ‘verklig’ för att, när man via numerisk analys (fint uttryck för simulering!) genomför en så kallad integration eller beräkning av modellen, kunna förutsäga hur fenomenet beter sig i verkligheten.

Numerisk analys

Till exempel simulering av solsystemet. Eller luftens passage förbi flygplansvingar, och hur det påverkar vingarna i kombination med hänsyn tagen till gravitation osv.

Båda dessa exempel, virtualisering (eller emulering) och fysik, strävar såklart efter att kunna förutsäga beteendet hos det subjekt man är intresserad av: WindowsXP, Commodore64, flygplansvingar eller solsystemet. 100% träffsäkehet är idealet.

Olika praktiska begränsningar medför att det kan vara svårt att nå de där 100%:en. Inom fysiken är det flera problem man har att brottas med: svårt att mäta indata till systemet, numeriska lösningsmetoder är i sin natur inte exakta (tal i datorer är begränsade i sin nogrannhet), okända fysiklagar (vi har inte en ”teori för allting” ännu) och inte minst: att det krävs oerhörd beräkningskraft för att genomföra beräkningarna (vi har inte tillgång till oändlig beräkningskraft, varken i tid eller minne).

I emuleringsfallet kommer istället svårigheten ifrån att subjektet ifråga, en PC, är komplicerad som attan. Det är svårt att få med allt i simuleringsprogramvaran: en modern PC är en av de mest komplicerade maskiner människan har skapat.

Nu kommer vi äntligen till den ryska dockans minsting! Min observation är följande:

Enhetstestning av programvara fungerar i mångt och mycket som en simulering av (delar av) programmet som utvecklas!

Även i detta fall strävar vi efter 100% prediktionskorrekthet (att kunna specificera programvarans beteende fullständigt), men faller här på praktiska ting som att det är svårt (dvs. dyrt) att enhetstesta vissa delar av program: GUI, tredjepartskod etc. Även den kombinatoriska explosion av användningsmöjligheter mjukvarusystem tyvärr ofta uppvisar, gör det praktiskt taget omöjligt att specificera samtliga vägar ett program kan gå.

Läs gärna mina inlägg om enhetstestning och test-driven utveckling, en moden vidareutveckling av enhetstestning.

Taggar: programmering, tdd, enhetstestning, simulering, emulering, virtualisering, pc, fysik

Intressant om TDD inom spelutveckling

Skumläste en intressant artikel om att applicera TDD-tekniken på spelutveckling. Spana in!

Taggar: programmering, tdd, spelutveckling