Mikael Deurell : Test

Skicka inte era testare till Provence

mikaeld — Tue, 28 Oct 2008 15:28:00 GMT

... för ännu en fördjupande utbildning i testmetodik... Vänta ett litet tag med att skicka era arkitekter på den hetaste arkitektutbildningen i Redmond. En av de mest påtagliga utmaningarna i vår bransch är att vi har suboptimerat teamen så hårt att vi glömt bort att vi är just det. Team! Vi har fått för oss att om vi har de individuellt bästa testarna, utvecklarna och arkitekterna inom varje skrå, med sina respektive metodiker, kommer vi bli bättre som team. Men en perfekt ITIL tillämpning eller testmetodik är inte helt optimal om den inte kan kopplas till en utvecklingsprocess.

Jag är övertygad om att det är bättre att bredda sig en aning. Test är ett perfekt verktyg för att knyta ihop och driva teamet framåt. Låt mig ge några exempel;

Testdriven arkitektur
Att använda enhetstester för att driva design börjar sakteliga sätta sig, men varför inte även använda tidiga utvecklardrivna lasttester för att adressera icke funktionella krav och skapa en mätbar baseline för er arkitektur? Hur ser era komponenter och tjänster ut när de fungerar optimalt? Hur ser de ut när de inte gör detta? Vilka aspekter skall ni titta på? Behöver ni komplettera med instrumentering? Varför inte automatisera detta i er byggprocess? Resultatet från detta arbete är det som skall övervakas i produktion.

Testdriven instrumentering och övervakning
Om vi i vår arkitektur har definierat vilka aspekter som skall testas, och i samband med detta även skapat en hälsomodell för applikationen är det exakt detta som skall övervakas i produktion. Avvikelser och driftstörningar i produktion kan återföras till arkitektursidan som förfinade lasttester.

Test är en lysande brygga mellan arkitektur och utveckling och mellan utveckling och drift. Det vackra är att det inte behövs inte några stora förändringar eller dyra verktyg, det är mest en inställningsfråga och arbetet kan drivas från de individuella teamen. Lasttester kan realiseras med enkla verktyg som tinyget och perfmon eller med mer sofistikerade verktyg som Visual Studio Team System och Team Foundation Server. Effekten? Energi, passion och bättre teamkänsla. Varför vänta?

Debugga i produktion eller testa bort i utvecklingsfas?

mikaeld — Tue, 30 Sep 2008 13:26:00 GMT

Enkelt svar hoppas jag... Jag tänkte visa ett exempel på hur ni kan debugga en låg cpu hängning i asp.net med hjälp av WinDbg. Jag är långt ifrån någon mästare i WinDbg men jag har grym nytta av mina debuggingkunskaper i egenskap av Solution Architect. Hela meningen med del 1 i denna screencast är att visa hur man kan debugga en hängning i produktion för att sedan i del 2 visa hur ni kan testa bort denna avvikelse med hjälp av Visual Studio Team System Test Edition (VSTEST).

Screencasts finns på Channel9 och ni har länkar till de två delarna nedan;

Del 1 - Debugga låg cpu hang i asp.net med WinDbg
Del 2 - %#& i att spendera tid i WinDbg och testa bort avvikelsen med VSTEST

Applikationen jag använder som bas i dessa screencasts är utvecklad av Tess Ferrandez och visar en hel del vanligt förekommande avvikelser. Lysande för att vässa era debugging och testkunskaper! Kan ni designa tester för att fånga samtliga avvikelser? Kan ni använda denna kunskap för att inte designa in dessa i er nästa arkitektur? Så klart ni kan... Öva, öva, öva! :-)

I used to rule the world
Seas would rise when I gave the word
Now in the morning I sleep alone
Sweep the streets I used to own...

Scrum i praktiken med Björn Eriksen

mikaeld — Sat, 22 Sep 2007 09:42:00 GMT

Björn har tagit fram en cool tvådagarskurs i Scrum/XP som är utformad på ett sätt som gör mig både avundsjuk och stolt! Jag får inte sällan frågor om att köra utbildning med just denna inriktning. Första dagen en ordentlig genomkörare av Scrum och andra dagen komplettera med engineering practices från XP och haka på verktygsstöd med BÅDE VSTS/TFS OCH ALT.net.

Björn kommer att jobba som MCT/ATE instruktör på TechEd i Barcelona, hugg tag i honom, bjud honom på tapas/öl och muta till er kursmaterialet... Eller gå kursen!!!

Bra jobbat Björn!!! You rock!

Micke lär sig mocka...

mikaeld — Mon, 29 Jan 2007 21:00:00 GMT

En härlig sak med mocking är att det samtidigt som jag får sköna unittests (utan integrationsstuff...) alltid får mig att snäppa upp min design. Mocking frameworks som NMock är bra men det går alldeles utmärkt att lämna dessa på hyllan och göra det hela själv... Och även om ni använder dem så måste ni ändå lura ut hur ni skall trixa in mockobjektet... Det viktigaste är ändå designen och det är oftast tre designval att välja mellan för att trycka in vårt fuskobjekt.... (Ingen hjärnkirurgi...)

- Dependency injection (Släng in mockobjektet i aktuell konstruktor)

public class Idol2007VotingService
{
private IVotingService remoteVotingService;
public Idol2007VotingService(IVotingService votingService)
{
remoteVotingService = votingService;
}
}

Det kassa med detta är att det bryter inkapslingen. Kan man leva med detta? Oftast... Om inte...

- Använd ett factoryobjekt

public class Idol2007VotingService
{
private IVotingService remoteVotingService;
public Idol2007VotingService()
{
remoteVotingService = ServiceFactory.CreateRemoteVotingService();
}
}

public class ServiceFactory
{
private static bool shouldCreateRemoteService = false;
public static IVotingService CreateRemoteVotingService()
{
if(shouldCreateRemoteService == true)
{
return new RemoteService();
}
else
{
return new MockService();
}
}
}

Det kassa med detta är att vi får ett dependency till test från vår produktionskod (mockobjektet). Kan vi leva med det? Om inte...

- Endo testing (subklasser kontrollerar dependency)

public class Idol2007VotingService
{
private IVotingService remoteVotingService;
public Idol2007VotingService()
{
remoteVotingService = createRemoteVotingService();
}

protected virtual IVotingService createRemoteVotingService()
{
return new RemoteVotingService();
}
}

Nu får vi det västa från alla världar... Cool! Subklasser är ansvariga för att skapa det aktuella objektet vilket gör att testklassen bara väljer vilken klass den skall skapa (Mocken) medan produktionskoden kör med basklassen (det riktiga objeketet)

Fördelar med endo testing:
- All testkod är inkapslad i subklasser (inte del av produktionskod)
- Snygg och klar gräns mellan test och produktionskod
- Klassen gör det den ska och vet inte om någonting om test

Micke erkänner:
När jag läste GOF på Universitetet kände jag mig ofta helt korkad. Jag kunde läsa ett stycke sådär en 10-15 gånger, förstå alla enskilda ord, men samtidigt inte ha en aning om vad det stycke jag just läst egentligen betydde. Jag såg mig själv lämna programmeringsbranschen för att istället satsa på grönsaksdisken på Matpiraten ända tills jag upptäckte "Head First Design Patterns". Helt plötsligt förstod jag! Att man kunde göra något så enkelt... Så svårt... GOF, ni var nära att få mig att sortera morötter... Men ni lyckades inte! Sweet!

UnitTest Kata from MSF Agile Essentials

mikaeld — Sun, 28 Jan 2007 21:58:00 GMT

Ni som varit med på UnitTest Katan från mina workshops och är intresserade av hur klasserna såg ut efter showen slutade kan kolla här! Ni kan ju gärna fortsätta refactoringresan (finns en hel del roliga saker att fixa till innan vi kan få deg för den... ;-)). Unittesterna följer Roy Osheroves lysande namnsättningsstandard (MethodName_StateUnderTest_ExpectedBehavior()) som rockar när ni har 500 unittests och enkelt vill få en överblick av vad "¤#% klassen skall göra... Glöm inte att separera logik (unittest) från integration (allt annat; ado fippel, webservices, mainframes, hårtorkar). Mocka bort det så får ni schyssare design på en gång (hey, ännu en sak som en riktig Arkitekt borde designa in i en leading shadow om några teammedlemmar behöver hjälp på resan...). Om det är otroligt meckigt att mocka det aktuella objektet, FUSKA, eller strunta i det... Det är ingen lag, ni kommer inte hamna i fängelse... I PROMISE! En del saker är ett %¤&# att mocka och det är inte alltid värt det...

Idag gick vi över 2200 visits på bloggen under januari (17220 hits). Tack för att jag hela tiden får lära mig nya saker av er och för att ni orkar läsa mina fummliga minnesanteckningar! En resa kvar till Tess Ferrandez nivå men... Jag jobbar på det... Jag har världens bästa jobb!!! :-)

using Bowler;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace BowlerTest
{
[TestClass]
public class Bowler
{
private Game game;

[TestInitialize]
public void InitBowler()
{
game = new Game();
}

[TestMethod]
public void Bowl_OnePinDown_Scores1()
{
game.Roll(1);
Assert.AreEqual(1, game.Score);
}

[TestMethod]
public void Bowl_20roundsAllOnes_Scores20()
{
RollMany(20, 1);
Assert.AreEqual(20, game.Score);
}

private void RollMany(int roundsToRoll, int pinsDown)
{
for (int currentRound = 0; currentRound < roundsToRoll; currentRound++)
{
game.Roll(pinsDown);
}
}

[TestMethod]
public void Bowl_SpareAndFive_Scores20()
{
game.Roll(6);
game.Roll(4);
game.Roll(5);
RollMany(17, 0);
Assert.AreEqual(20, game.Score);
}

[TestMethod]
public void Bowl_TwoFourAndStrikeAndFiveTwo_Scores30()
{
game.Roll(2);
game.Roll(4);
game.Roll(10);
game.Roll(0);
game.Roll(5);
game.Roll(2);
RollMany(14,0);
Assert.AreEqual(30,game.Score);
}
}
}

namespace Bowler
{
public class Game
{
private int[] rounds = new int[21];
private int currentRound;

public int Score
{
get
{
int score = 0;
int frameIndex = 0;
for (int currentFrame = 0; currentFrame < 10; currentFrame++)
{
if (isStrike(frameIndex))
{
score += strikeScore(frameIndex);
}
else if (isSpare(frameIndex))
{
score += spareScore(frameIndex);
}
else
{
score += frameScore(frameIndex);
}
frameIndex += 2;
}
return score;
}
}

private bool isStrike(int frameIndex)
{
return rounds[frameIndex] == 10;
}

private int spareScore(int frameIndex)
{
return 10 + rounds[frameIndex + 2];
}

private bool isSpare(int frameIndex)
{
return rounds[frameIndex] + rounds[frameIndex + 1] == 10;
}

private int strikeScore(int frameIndex)
{
return 10 + rounds[frameIndex + 2] + rounds[frameIndex + 3];
}

private int frameScore(int frameIndex)
{
return rounds[frameIndex] + rounds[frameIndex + 1];
}

public void Roll(int pinsDown)
{
rounds[currentRound] = pinsDown;
currentRound++;
}
}
}

I, I was only wondering
If you could ever change your mind
You could give it up but soemthing might happen
It's all too much but something might happen
You'll break this cup but something might happen

So break this cup 'cause something might happen...

Jet Brains

mikaeld — Thu, 14 Dec 2006 21:39:00 GMT

JetBrains har precis släppt Resharper 2.5. Så bra att jag lagt bort min gamla trogna Visual Assist... Det jag älskar (förutom det att man aldrig behöver fippla med musen för att göra sitt jobb utan utnyttja tangentbordet som ändå är precis under fingrarna) är integrationen mot NUnit och csUnit, refactoringstödet och... Ja... Testa själva... ;-)

I want to go out tonight.
Cut me a little closer to the city lights.
Levitation ain’t your only friend.
Levitation coming back again.
You feel a burning in your body core.
It’s a yearning that you can’t ignore.