Testning är en väldigt viktig del i ett projekt, då testning ger en större chans till att göra en vara av bra kvalitet.
Testning av kod är en iterativ process där koden först skapas, och sedan testas med hjälp av testfall. Dessa testfall består av instruktioner för hur specifika tester ska gå till samt vad som ska bli resultatet efter att testet är gjort.
Ett exempel på testfall kan vara att en person ska kunna lägga till en vara i en virtuell kundvagn, förslagsvis en sådan man hittar på en ordinär e-handelsplats.
I testfallsbeskrivningen skulle det i detta fall kunna stå något i stil med:
- Testfall
- Tänkt Åtgärd
- Resultat
- Testad
Att lägga till en vara i kundvagnen med hjälp av en knapptryckning, varefter varan ska dyka upp en kundvagnen. Efter användaren valt vilken vara den vill köpa, trycker den på knappen ’lägg i kundvagn’. Vara i kundvagn.
Ja
Notera att ett testfall inte behöver se ut på detta vis, jag gjorde bara så här för att jag tyckte det var ett tillräckligt tydligt exempel.
Under Resultat står det nu ’Vara i kundvagn’, alltså fungerar funktionen. Detta är dock inte alltid fallet. I ett ej fungerande fall, som till exempel att programmet/webbsidan kraschar efter man tryckt på knappen, skriver man detta istället under ’Resultat’ och börjar med att försöka lösa problemet. Man felsöker nu koden och skriver om den när man hittat felet och gör om testet igen.
Detta kan upprepas flera gånger tills problemet är borta, och det är därför som man kallar testningen för iterativ, upprepande.
Om man till slut hittat och åtgärdat problemet, fyller man i det som ett positivt resultat och kan pusta ut. Eller?
Även om man lyckats lösa problemet och allt fungerar utmärkt, kan man ibland ändå få gå tillbaka till gamla testfall och undersöka om dessa fortfarande fungerar. Detta är på grund av att, så länge som projektet inte är slutfört och personer fortfarande håller på med utvecklingen av det, så kan andra delar av huvudprogrammet som ens fina kundvagnsprogram bygger på få problem.
Kanske till och med personens lösning av problemet skapade problem hos de andra delarna.
I komplexa program är detta problem svårare att lösa än i mindre komplexa, och det enda man kan göra för att förhindra, eller i alla fall minska, detta problem, är att organisera alla parter i projeket, och införa ett arbetssätt som får alla att arbeta mer som ’en och samma person’.
Återanvändning av kod
När man kodar i ett modernt programmeringsspråk finns det tusentals fördefinierade klasser att använda sig av. Dessa klasser innehåller färdigskriven kod och används för att programmeraren inte ska behöva skriva all kod själv. Användningen av dessa kan vara ett mycket tidsmässigt lönsamt beslut, då koden i klasserna både kan vara lång och komplicerad.
Ett exempel på en klass är Math. Math innehåller en stor mängd matematiska funktioner som kan vara mycket svårbegripliga och som programmeraren kanske inte ens är kvalificerad att klara av att koda själv. Och nu har vi hittat ännu en fördel med klasser, nämligen att man programmeraren inte alltid behöver kunna koda allt, utan bara behöver veta hur klasserna används.
Klasserna fungerar alltså som ett slags fördefinierade objekt som programmeraren kan använda för att skapa nya fristående objekt med. Att skapa ett objekt av en klass kallas för Instansiering.
Det är av denna anledningen som språken med denna funktion kallas för objektorienterade.
Äldre språk, tex blablabla är inte objektorienterade, detta betyder att man, istället för att använda klasser vid upprepande platser i källkoden, måste man skriva allt om och om igen.
Detta är inte bara tidsödslande utan koden blir också lång och jobbig att läsa.
Det första objektorienterade språket är – <insert text heargh>
anledningen till att skaparen av – tillverkade språket var att <insert text heargh>
Det beror hur som helst in bara på om språket är objektorienterat eller ej om koden ska vara återanvändningsbar, visserligen blir den det automatiskt till viss del vid användning av ett objektorienterat språk, men mycket beror också på hur programmeraren skriver sin kod.
Programmeraren bör skriva koden så lättförståelig som möjligt utan att detta inverkar för mycket på kodens effektivitet. Detta är för att andra programmerare lättare ska kunna sätta sig in i koden ifall ett ändringsbehov skulle uppstå, vilket det med stor sannolikhet också kommer göra.
Koden inte bara vara lättförstålig, den ska också vara lätt att bygga ut, eller uppdatera, och detta görs förslagsvis genom att kodens metoder