PG 1.5 Debugging

Table of contents

• Testning
• Allmänt om testing
  • Verifiering och Validering (V&V)
  • Mål med testning
• TDD - testdriven utveckling
  • Hur går TDD till?
• Jest
  • Skapa ett enkelt test
• PUT - Parametericiced Unit Test
  • Göra enkelt PUT test

Testning

Jest, unit testing, TDD, PUT (Parametericed Unit Testing).

Allmänt om testing

• Testning är en stor del av det totala arbetet med utveckling
• När ett program är redo för deployment går det över i maintenance mode. Här läggs mycket tid på att se till att gamla versioner funkar (regression)
• Att skapa upp och starta en första version av en att går väldigt fort jämfört med hur länge den är i maintenance och testas

Verifiering och Validering (V&V)

Validering

• Bygger vi rätt produkt/feature?
• Sker när något är klart
• Fyller resultet behovet som fick oss att skapa den?

Verifiering

• Bygger vi produkten rätt?
• Sker under arbetets gång
• Kolla av om produkten når specifikationer och krav

Mål med testning

Två saker:

• Visa för utvecklare och kund att produkten fungerar och möter kraven
  • Det ska finnas ett kravdokument
  • Ett test för varje krav i ovanstående
  • Testa alla fel som skulle kunna göras!
  • Varje feature blir testat som en del av production release
• Hitta inputs eller inputsekvenser som g ör att features inte ger det resultat eller behavior som man antog. Man försöker ta bort defekter som annars skulle kunna leda till crashar eller oväntade resultat.

TDD - testdriven utveckling

Testerna skrivs först! Då kan du sen skriva funktioner som du vet håller för det de ska hålla för. Funkar bäst om du inte behöver tänka på GUI eller UI/UX, t.ex. i backend sammanhang. Det kan gå att testa GUI när saker som kan hämtas programmatiskt testas (storlek på skärm etc), men UI/UX kan mest bli problematiskt.

Fördelar med TDD:

• Code coverage - säkerställer att varje funktion får minst ett test
• Regression testing - säkerställer att det finns en suite med tester för alla gamla krav och tidigare funktioner, vilket underlättar väldigt mycket för regression. Så fort en ny funktion läggs till är det lätt att testa alla gamla funktioner.
• Förenklad debugging - mycket lättare att se var eventuella problem uppstår
• Systemdokumentation - testerna kan hjälpa att förklara hur funktioner används och bli på så sätt en del av dokumentationen (varje test blir ett exempel på användning av den specifika funktionen)

Hur går TDD till?

1. Skriv ett test
2. Kör test
3. Se att det failar
4. Implementera funktionalitet och refaktor (förbättra)
5. Pass (förhoppningsvis)
6. Tillbaka till steg 1!

Jest

Ett verktyg för att testa JavaScript.

Enkelt exempel (inte TDD):

1. Skapa en mapp
2. npm init
3. npm install --save-dev jest eller yarn add --dev jest
4. Lägg in jest i scripts i package.json

Skapa ett enkelt test

Skapa filerna sum.js och sum.test.

sum.js:

function sum (a, b) {
	return a + b;
}
module.exports = sum;

sum.test.js:

const sum = require ('./sum');

test ('adds 1 + 2 to equal 3', () => {
	expect(sum(1, 2)).toBe(3);
});

Köra testet:

$ npm test

När vi kör TDD skulle vi göra i en lite annan ordning. Till att börja med skulle vi göra steg 1-4 på samma sätt. När det väl handlar om att skapa själva filerna skulle vi först göra testet, sedan testa att köra det, se att resultatet blev fail, sedan testa att skapa funktionaliteten, sedan köra igen och så vidare.

PUT - Parametericiced Unit Test

En av de senaste trenderna inom unit testing. Går ut på att göra om sina tester till parametericerade former för att undvika att behöva skriva om många tester. Detta kan vara bra för att testa sk edge cases.

Göra enkelt PUT test

I put.test.js:

test.each([
	[1, 1, 4], // ska faila
	[1, 2, 3], // ska gå igenom
	[2, 1, 3], // ska gå igenom
])('.add(%i, %i)', (a, b, expected) => {
	expect (a + b).toBe(expected);
});

toBe -> mer primitivt än toEqual, används för enklare grejer