Skip to content

Latest commit

 

History

History
280 lines (187 loc) · 7.41 KB

10.2.testing.md

File metadata and controls

280 lines (187 loc) · 7.41 KB
title
Fyrirlestur 10.1 — Context

Fyrirlestur 10.2 — Testing

Vefforritun 2 — HBV403G

Ólafur Sverrir Kjartansson, osk@hi.is

Sjálfvirkar prófanir

  • Þegar við skrifum kóða erum við alltaf að athuga hvernig hann virkar
  • Gerum það yfirleitt handvirkt
  • Hvað ef við skrifum forrit sem framkvæmir handvirku prófanirnar?
  • Getum framkvæmt handvirku prófunina margfalt hraðar
  • Getum framkvæmt margar handvirkar prófanir saman, hratt
  • Framkvæmum alltaf eins

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 forrit
  • 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
  • Hvernig prófum við kóða sem tekur tillit til tíma? Bæði upp á nákvæmar dagsetningar og að tími líði?
  • Getum mockað dagsetningar, eða sent inn Date hlut í staðinn fyrir að nota hann „harðkóðaðann“
function inside(lower, upper) {
  const date = new Date();

  return lower < date && date < upper;
}
// vs...
function inside2(lower, upper, _Date) {
  const date = new _Date();

  return lower < date && date < upper;
}

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 === true);
  • Æ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
  • Mikil einföldun á flóknara hugtaki
  • x ætti að vera jafnt y
  • result.should.equal(true)
  • býst við að x sé jafnt y
  • expect(result).to.equal(true);

Code coverage

  • Hversu stórt hlutfall af kóðanum okkar er prófaður?
  • Getur verið fyrir mismunandi hluta forrits, t.d.
    • 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

Integration tests

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

Jest

  • jest er test framework frá Facebook
  • Orðið frekar vinsælt og sérstaklega með React
  • Kemur uppsett með create-react-app sjá skjölun
import React from 'react';
import { test, expect } from '@jest/globals';
import { render, screen } from '@testing-library/react';
import App from './App';

test('renders learn react link', () => {
  render(<App />);
  const linkElement =
    screen.getByText(/learn react/i);
  expect(linkElement)
    .toBeInTheDocument();
});

Önnur test library

  • 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

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ð main 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)
  • Ákveðið traust að main sé alltaf útgáfuhæft

Continuous deployment

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

end-to-end tests

  • e2e
  • Hermir eftir notanda, slær inn í form, ýtir á takka o.s.fr.
  • „Forritum“ hegðun notanda, keyrum „forritið“ á móti vefnum okkar og athugum hvort niðurstöður séu réttar

Cypress

  • e2e testing tól
  • Sækjum með npm en mun nota þá vafra sem uppsettir eru á vél til að keyra próf
  • Opnar vafra í forritanlegu umhverfi sem kann að keyra Cypress próf
it('.submit() - submit a form', () => {
  // https://on.cypress.io/submit
  cy.get('.action-form')
    .find('[type="text"]').type('HALFOFF');

  cy.get('.action-form').submit()
    .next()
    .should(
      'contain',
      'Your form has been submitted!',
    );
});