Python+Ubuntu+TDD

19 december 2009

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: , , , , ,

Annonser

MVP pattern practice, part 1

26 september 2009

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:

gui-schematic
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: , , , , ,


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

15 september 2009

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: , , ,


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

12 juli 2009

(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: , , , ,


Två kollaborativa textprogram

05 juli 2009

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

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

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: , , , , , ,


Död programkod

15 april 2009

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: , , ,


Testing filters

07 april 2009

muir-woods-mossy-fernsSo 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: , , ,


%d bloggare gillar detta: