Lage brukere, lage innhold, endre kode, endre innhold, teste manuelt, endre et felt, teste igjen, ny database, nytt alt, på an igjen. Nårt man utvikler litt mer enn grunnleggende systemer i Drupal er det lett å miste tråden, og det er lett å bruke mer tid på manuell testing enn man tror at man egentlig har brukt. I tillegg til å bevege seg bort fra opprinnelig spec har man kanskje opplevd:
-
Kode man har skrevet som løser en oppgave, ender opp med å ha ødelagt en eller annen obskur kritisk funksjonalitet som en ikke engang visste* eksisterte
-
Sikkerhetsoppdateringer kjøres ut og tar knekken på den obskure funksjonaliteten som en ikke engang visste* eksisterte.
-
Deng (eller enda verre, sukk og stønn) fra medarbeidere om du overleverer et system med mangelfull teknisk dokumentasjon på den funksjonaliteten som en allerede har glemt* eksisterer
-
Husdyret som ikke visste bedre og tråkket på laptoptastaturet ditt og la inn en skrivefeil i en obskur kodeklasse som ikke ble plukket opp av phpcs og som uheldigvis ble committet og kjørt ut på produksjon
Dette er i og for seg “tradisjonelle problemstillinger” mtp tester i utvikling og vedlikehold, sett fra en utviklers perspektiv. Men hvordan kan du bruke tester proaktivt i samarbeidet med kunden, og på den måten synliggjøre nødvendigheten, mulighetene og fordelene av å prioritere disse?
Jeg skal ta for meg utvikling i Drupal 8 basert rundt tester basert på Behat / Mink, og hva slike tester kan gjøre for deg og din kunde. I Drupal 8 er det blitt skremmende enkelt å teste!
-
Hvordan selge inn tester hos eksisterende kunder
-
De virkelige fordelene med å skrive tester (spesielt på D8)
-
Hvorfor du på nye prosjekter bør “do it anyway”, som del av den tekniske utformingen
-
Gjennomgang av en basic test setup basert på Composer og Drupal 8
-
Vi tar for oss verktøy for visualisering av testresultater som dokumentasjon på endringer