Slik tester Web-koden?

stemmer
11

Er det noen som har noen gode tips for å skrive test kode for database-backend utvikling der det er en tung avhengighet av staten?

Spesielt ønsker jeg å skrive tester for kode som henter poster fra databasen, men svarene vil avhenge av data i databasen (som kan endres over tid).

Har folk vanligvis lage en egen utviklingssystem med en 'frosset' database, slik at enhver funksjon bør alltid tilbake nøyaktig samme resultat sett?

Jeg er ganske sikker på at dette ikke er et nytt problem, så jeg ville være veldig interessert i å lære av andres erfaringer.

Er det gode artikler der ute som diskuterer denne utgaven av web-basert utvikling generelt?

Jeg pleier å skrive PHP-kode, men jeg forventer alle disse problemene er i stor grad språk og rammeverk agnostiker.

Publisert på 05/08/2008 klokken 21:58
kilden bruker
På andre språk...                            


10 svar

stemmer
5

Du bør se nærmere DBUnit, eller prøve å finne en PHP tilsvarende (det må være en der ute). Du kan bruke den til å forberede databasen med et bestemt sett av data som representerer dine testdata, og dermed hver test vil ikke lenger være avhengig av databasen og noen eksisterende tilstand. På denne måten er hver test selvforsynt og vil ikke bryte løpet videre database bruk.

Oppdatering: En rask google søk viste en DB enhet forlengelse for PHPUnit.

Svarte 05/08/2008 kl. 22:03
kilden bruker

stemmer
3

Hvis du er mest opptatt av datalaget testing, kan det være lurt å sjekke ut denne boken: xUnit Testmønstre: Refactoring Test kode . Jeg var alltid usikker på om det selv, men denne boken gjør en god jobb for å hjelpe nummerere bekymringene som ytelse, reproduserbarhet, etc.

Svarte 06/08/2008 kl. 04:14
kilden bruker

stemmer
2

Vi bruker en in-memory database (HSQL: http://hsqldb.org/ ). Dvalemodus ( http://www.hibernate.org/ ) gjør det enkelt for oss å påpeke våre andels tester på testing db, med den ekstra bonus at de kjører så fort som lynet ..

Svarte 10/09/2008 kl. 12:02
kilden bruker

stemmer
2

Jeg antar det avhenger av hva databasen du bruker, men Red Gate (www.red-gate.com) lage et verktøy som heter SQL Data Generator. Dette kan konfigureres til å fylle databasen med fornuftige jakt testdata. Du kan også be den om å alltid bruke samme frø i sin tilfeldig tall generator slik at 'tilfeldig' data er det samme hver gang.

Deretter kan du skrive dine enhet tester for å gjøre bruk av denne pålitelige, repeterbare data.

Som for testing av web siden av ting, jeg for tiden ute i selen (selenium.openqa.org). Dette synes å være en cross-browser stand test suite som vil hjelpe deg å teste funksjonaliteten. Men som med alle disse web site testverktøy, det er ingen reell måte å teste hvor godt disse tingene ser i alle nettlesere uten å kaste et menneskelig øye over dem!

Svarte 06/08/2008 kl. 13:44
kilden bruker

stemmer
1

Generelt Jeg er enig med Peter, men for å skape og sletting av testdata Jeg ville ikke bruke SQL direkte. Jeg foretrekker å bruke noen CRUD API som brukes i produktet for å lage data som ligner på produksjon som mulig ...

Svarte 10/09/2008 kl. 11:31
kilden bruker

stemmer
1

Jeg vil foreslå å bruke tre databaser. En produksjonsdatabasen, en utvikling database (fylt med noen meningsfylte data for hver utvikler) og en test database (med tomme bord og kanskje et par rader som alltid er nødvendig).

En måte å teste database kode er:

  1. Sett noen rader (ved hjelp av SQL) til å initialtilstand
  2. Kjør funksjonen som du vil teste
  3. Sammenlign forventet med faktiske resultater. Her kan du bruke ditt vanlige enhet testing rammeverk
  4. Rydd opp radene som ble endret (så neste løp vil ikke se forrige løp)

Opprydding kunne gjøres på en standard måte (selvsagt bare i test database) med DELETE * FROM table.

Svarte 19/08/2008 kl. 18:40
kilden bruker

stemmer
1

Her er min strategi (jeg bruker JUnit, men jeg er sikker på at det er en måte å gjøre tilsvarende i PHP):

Jeg har en metode som går før alle enheten testene for en bestemt DAO klasse. Det setter dev database til en kjent tilstand (legger all testdata, etc.). Som jeg kjøre tester, jeg holde oversikt over alle data lagt til i kjent tilstand. Denne informasjonen blir ryddet opp ved slutten av hver test. Etter at alle testene for klassen har kjørt, fjerner en annen metode alle testdata i dev databasen, slik at det i den tilstanden den var i før testene ble kjørt. Det er litt arbeid å gjøre alt dette, men jeg pleier å skrive metodene i en DBTestCommon klasse der alle mine DAO test klasser kan komme til dem.

Svarte 11/08/2008 kl. 13:30
kilden bruker

stemmer
1

Du kan prøve http://selenium.openqa.org/ det er mer for GUI testing i stedet for en datalaget testing program, men ikke ta opp dine handlinger som deretter kan spilles av for å automatisere tester på tvers av ulike plattformer.

Svarte 06/08/2008 kl. 12:06
kilden bruker

stemmer
1

Hvis du kan sette opp databasen med en kjent mengde før du kjører testene og rive ned på slutten, så du vet hvilke data du jobber med.

Deretter kan du bruke noe sånt Selen å enkelt teste fra UI (forutsatt webbasert her, men det er mange UI testverktøy der ute for andre UI-smaker) og oppdage tilstedeværelsen av visse poster trukket tilbake fra databasen.

Det er definitivt verdt å sette opp enten en testversjon av databasen - eller lage dine testskript fylle databasen med kjente data som en del av testene.

Svarte 05/08/2008 kl. 22:08
kilden bruker

stemmer
1

Jeg har nøyaktig samme problem med mitt arbeid og jeg synes at den beste ideen er å ha et PHP-skript for å gjenskape databasen og deretter en egen script der jeg kaster gale data på den for å se om det bryter den.

Jeg har ikke brukt noen Unit testing eller lignende så kan ikke si om det fungerer eller ikke lei.

Svarte 05/08/2008 kl. 22:03
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more