Skip to content

Latest commit

 

History

History
265 lines (179 loc) · 7.7 KB

11.2.testing.md

File metadata and controls

265 lines (179 loc) · 7.7 KB
Raw

Fyrirlestur 11.2

Testing

Vefforritun 2 — HBV403G

Ólafur Sverrir Kjartansson, [email protected]

Sjálfvirkar prófanir

  • Þegar við skrifum kóða erum við alltaf að athuga hvernig hann virkar
  • Gerum það yfirleitt handvirkt
  • Getum eytt tíma og skrifað próf fyrir þessa handvirku athugun

Kostir prófa

  • Getum keyrt mörg próf hratt, aftur og aftur
  • „Notum“ kóðann okkar á meðan við skrifum hann, getum endað með betra API
  • Gefur okkur ákveðið traust á virkni og að við munum ekki brjóta hana seinna meir

Ókostir prófa

  • Það tekur töluvert lengri tíma að skrifa próf en að athuga eitthvað handvirkt
  • Geta gefið okkur falskt öryggi um að það séu ekki villur í kóðanum okkar því við skrifuðum próf
  • Við breytingar á kóða þarf að uppfæra próf og ef það er erfitt er mun auðveldara að slökkva bara á þeim

Unit test

  • Ekki vel skilgreint hugtak en..
  • Próf á einni einingu í einu án þess að horfa á alla heildina
    • Eining gæti verið fall, klasi, módull
  • Sumir segja að unit test eigi ekki að snerta á I/O eða einhverju fyrir utan einingu
  • Hjálpa okkur við að komast að því hvernig við viljum smíða forritið okkar
  • Fáum endurgjöf hratt og örugglega meðan við erum að skrifa
  • Leyfa okkur að breyta kóða með vissu öryggi — erum með próf til staðar sem grípa villur
  • Prófin geta komið í stað eða aukið við skjölun, sýna bókstaflega hvernig kerfið virkar
  • Fyrir villur sem finnast getum við skrifað próf áður en við lögum
    • Minnkum líkur á að villa komi upp aftur

Skilvirk test

  • Einföld & DRY (Don't Repeat Yourself)
    • Einn hlutur í einu
  • Óhað röð sem þau eru keyrð í
  • Endurtakanleg (repeatable) með sömu niðurstöðum
  • Hröð
    • Gæti falið í sér að mocka út allar þjónustur og stöður

Mocks og stubs

  • Mocks herma eftir hlutum þ.a. við vitum nákvæmlega hvernig hegðun verður
  • Notum ef hlutur er hægur, flókinn, brigðgengur (non-deterministic) o.fl.
  • Stubs (stundum kallað fake) eru stubbar sem við skrifum í staðinn fyrir virkni, t.d. að láta fall alltaf skila sömu niðurstöðu
  • Þegar við prófum og notum mocks þurfum við að passa að prófa ekki bara þau sjálf, heldur einblína á að prófa raunverulega virkni
  • Mocks, stubs og fakes eru ekki vel skilgreind hugtök og notuð á mismunandi hátt af mismunandi aðilum

Test harness, test frameworks

  • Forrit og stillingar sem sjá um að keyra prófin okkar
  • Taka saman niðurstöður og láta vita stöðuna
  • Get keyrt virkni fyrir og eftir hvert próf eða fyrir og eftir öll próf

Assertions — staðhæfingar

  • Við skrifum prófin okkar þ.a. þau staðhæfi eitthvað í lokin
    • Við gefum rétt gildi og athugum hvort það sé eins
    • assert(result === 'foo');
  • Ættum að hafa færri en fleiri staðhæfingar í hverju prófi
    • ekki gera of mikið
  • Ein leið til að skipuleggja próf er að fylgja arrange, act, assert

Arrange, Act, Assert

const input = 'bar';        // Arrange

const res = reverse(input); // Act

assert(res === 'rab');      // Assert

Test-driven development (TDD)

Endurtökum:

  1. Byrjum á að skrifa próf sem bregst
  2. Skrifum kóða til að láta prófið (og öll önnur próf) heppnast
  3. Hreinsum kóða og keyrum próf

TDD flæði

Behavior-driven development (BDD)

  • Svipar til TDD en einblínir á virkni en ekki prófin sjálf
  • Breytum því hvernig við skrifum staðhæfingar og notum
    • x ætti að vera jafnt y
    • foo.should.equal('bar')
    • býst við að x sé jafnt y
    • expect(foo).to.equal('bar');
  • Mikil einföldun á flóknara hugtaki

Code coverage

  • Hversu stórt hlutfall af kóðanum okkar er prófaður?
  • Nokkrar skilgreiningar
    • function - hlutfall falla sem kallað er í
    • statement - er hver skipun keyrð?
    • branch - hefur hver grein verið prófuð? T.d. bæði if og else
    • condition - hafa allar segðir verið prófaðar? T.d. foo && bar fyrir alla fjóra möguleika

Integration tests

  • Prófa fleiri en eina einingu í einu
    • Uppflettingar í gagnagrunn
    • Samskipti yfir net
    • O.fl.
  • Gætu tekið lengri tíma

Unit test og node.js

  • Mocha er test framework sem styður mörg assertion library
  • Chai er assertion library sem styður assert, should og expect
  • Sinon sér um mocks og stubs
  • istanbul fyrir code coverage
  • Nock prófar HTTP beiðnir

Mocha

  • Setjum upp test suite með describe
  • Hvert test er innan it(description, test)
    • description er lýsing á prófi sem byrjar á should
    • test er prófið sjálft sem fall
  • Getum prófað ósamfasa kóða með async await í Mocha

Mocha keyrsla

  • Setjum upp almennt
    • npm install -g mocha
  • Getum keyrt með mörgum flöggum, t.d.:
    • -w - Fylgjast með skrá og keyra ef breytist
    • -R - Hvernig niðurstaða lítur út, t.d. spec, dot

Mocha & Chai dæmi

const chai = require('chai');
chai.should();

describe('Array', () => {
  describe('#indexOf()', () => {
    it('should return -1 when the value is not present', () => {
      [1,2,3].indexOf(5).should.equal(-1);
    });
  });
});

Jest

  • jest er test framework frá Facebook
  • Orðið frekar vinsælt og sérstaklega með React
  • Kemur uppsett með create-react-app og í skjölun eru ítarlegar leiðbeiningar
  • Getum notað með enzyme til að staðfesta útkomu úr componentum
import React from 'react';
import { shallow } from 'enzyme';
import App from './App';

it('renders welcome message', () => {
  const wrapper = shallow(<App />);
  const welcome = <h2>Welcome to React</h2>;
  expect(wrapper.contains(welcome)).toEqual(true);
});

Continuous integration

  • Continuous integration (CI) er þegar við keyrum öll test við hvert commit í source control
  • „Integration“ kemur frá því að við erum að integratea við master branch
    • Ef það er gert sjaldan getur komið upp staða þar sem gefa á út og það þarf að mergea mörgu í einu
    • Integration hell
  • Höfum ákveðið traust á því að master sé alltaf tilbúið til útgáfu

Continuous deployment

  • Continuous deployment er þegar við gefum master út á raunkerfi fyrir hverja breytingu sem stenst próf
  • Höldum master alltaf í deployable ástandi
  • Hægt að gefa út oft á dag

Heroku CI

  • Getum sett upp CI á Heroku ef við notum pipelines
  • Skilgreinum nokkur öpp saman í pipeline, t.d.
    • dev, alltaf nýjasta útgáfa af master, tengist þróunarþjónustum
    • test, útgáfa sem verið er að fara að gefa út, tengist raunþjónustum eða afriti af þeim
    • prod, raunkeyrsla á kerfi
  • Ef við tengjum pipeline við GitHub getum við sjálfkrafa búið til ný öpp fyrir hvert PR
  • create-react-app buildpack hefur stuðning við Heroku CI
  • Heroku + Git + test + CI = 😍

Aðrar CI þjónustur