Cucumber på Android. (ny titel) Del 4 – Hur går jag vidare?

BostonGurka

Kör nu mina tester på target och det är lika kul varje gång det funkar! 🙂 Dock är det nu dags att gå vidare…

För tillfället så har man tillgång till selenium sviten och jetty prylarna för att kunna snacka med en browser men jag vill ju kunna generiskt öppna upp fler saker än browsern…

Graphics ligger mig närmast hjärtat så OpenGL, Renderscript, canvas osv är intressant men även UI och telephony.

UI är inte svårt eftersom man kan använda sig av driver.findElementByText(value) så länge det finns id taggade element i UI’t men så ser det inte ut med allt som ritas på skärmen… Telephony är enkelt likaså men hur testar man att en box ritas på rätt sätt med OpenGLES på två olika plattformar och olika kakor? Jag har en idé här men den håller jag för mig själv en stund till 😉

Givetvis så tillämpar man design for testability när man utvecklar men det är trevligt att inte behöva uppfinna hjulet varje gång och fler än jag är troligtvis intresserad av att kunna testa andra saker än browsern eller statiska UI element!

Frågan nu är skall jag skriva en GfxDriver som bygger på SearchContext som WebDriver gör och mappa allt därunder eller skall jag skriva min egen native driver efter det som passar mina syften? Jag lutar åt att göra min egen modell för detta som jag sen bygger vidare på med alla andra funktioner som behövs i framtiden.

Projektet just nu är lite känsligt att flytta eftersom det har en massa beroenden både hit och dit och mer än en gång har Maven kastat in en skiftnyckel i maskineriet när jag har flyttat koden mellan datorer men det måste jag bena ut för testprojekt måste vara portabla och framförallt lätta att implementera – annars kommer ingen att använda det och hela syftet åker ner i toaletten.

I min värld så skall det räcka med någon include och lite boilerplate kod, sen skall man vara uppe och snurra!

Jag har slagits för termen “rätt kvalitet” och testbarhet i över 20 år nu och det kommer jag att fortsätta med tills jag dör! Det finns fortfarande många i industrin som tror att vattenfall funkar och att test är något man kan lägga på en extern organisation… Det visar bara på hur lite koll man har på läget!

Skall vattenfall fungera så kräver det att ALLA krav är på plats INNAN man börjar implementera och att ändringar hålls till ett MINIMUM samt att planen ÄNDRAS vid VARJE ändring! När jag jobbade med vattenfall så skrev jag först en Implementation Proposal på kodnivå som sen programmeraren fick. Den var han/hon tvungen att följa slaviskt för att det skulle fungera som jag hade planerat. När denna process följdes till 100% så kunde man skicka saker på test men så funkar inte världen i dag och då är de agila metoderna de enda som fungerar.

BDD tog steget vidare och fokuserade på beteenden och inte de individuella testerna och jag strävar alltid efter dynamiska tester eftersom jag finner statiska tester menlösa. Hur många gånger har man inte sett någon visa testautomatisering och det enbart handlar om statiska testfall som inte hanterar de returnerade värdena… Det testar enbart syntaxmässigt koden, inte hur det kommer att funka i flödena!

Hur som haver så är detta en spännande resa och jag har fått börja koda igen, vilket jag svor på att aldrig göra igen, men ibland får man göra saker själv för att få det som man vill ha det! Jag är en tämligen medioker utvecklare om jag får säga det själv men jag kan en hel del om det mesta och där det krävs djupare domänkunskaper i vissa områden så har jag experthjälp av mina kollegor! Test är en annan femma och här har jag absolut koll på prylarna!

Given, When, Then…

Har ni inte redan gissat det så kommer projektet att heta BostonGurka, bara så ni vet! 😀

Author: politisktinkorrektpappa

Share This Post On

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.