Hva er enhetstesting?

stemmer
198

Jeg så mange spørsmål å spørre 'hvordan' til enheten test på et bestemt språk, men ingen tvil spør 'hva', 'hvorfor', og 'når'.

  • Hva er det?
  • Hva gjør det for meg?
  • Hvorfor skal jeg bruke det?
  • Når bør jeg bruke det (også når den ikke er)?
  • Hva er noen vanlige fallgruver og misforståelser
Publisert på 04/08/2008 klokken 16:27
kilden bruker
På andre språk...                            


20 svar

stemmer
186

Enhetstesting er, grovt sett, testing biter av koden isolert med testkoden. De umiddelbare fordeler som kommer til hjernen er:

  • Kjøre testene blir automat-stand og repeterbare
  • Du kan teste på en mye mer detaljert nivå enn pek-og-klikk-testing via en GUI

Merk at hvis testkoden skriver til en fil, åpner en database tilkobling eller gjør noe over nettverket, er det mer hensiktsmessig kategorisert som en integrasjonstest. Integrasjonstester er en god ting, men må ikke forveksles med enhet tester. Enhet test koden skal være kort, søt og rask å utføre.

En annen måte å se på enhetstesting er at du skriver testene først. Dette er kjent som testdrevet utvikling (TDD for kort). TDD bringer ekstra fordeler:

  • Du skriver ikke spekulativ "Jeg trenger dette i fremtiden" code - akkurat nok til å gjøre testene passere
  • Koden du har skrevet er alltid dekket av tester
  • Ved å skrive testen først, er du tvunget til å tenke gjennom hvordan du ønsker å ringe koden, som vanligvis forbedrer utformingen av koden i det lange løp.

Hvis du ikke gjør enhetstesting nå, anbefaler jeg deg å komme i gang på den. Få en god bok, praktisk talt alle xUnit-boken vil gjøre fordi begrepene er svært mye overførbar mellom dem.

Noen ganger skriver enhet tester kan være smertefullt. Når det blir sånn, prøve å finne noen til å hjelpe deg, og motstå fristelsen til å "bare skrive den jævla koden". Enhetstesting er mye som oppvasken. Det er ikke alltid hyggelig, men det holder metaforisk kjøkkenet rent, og du virkelig vil at det skal være ren. :)


Edit: En misforståelse kommer til hjernen, men jeg er ikke sikker på om det er så vanlig. Jeg har hørt en prosjektleder si at enheten tester gjort teamet skrive all koden to ganger. Hvis det ser ut og føles sånn, vel, du gjør det galt. Ikke bare skrive testene vanligvis fart på utviklingen, men det gir deg også en praktisk "nå er jeg ferdig" indikator på at du ikke ville ha noe annet.

Svarte 04/08/2008 kl. 16:36
kilden bruker

stemmer
66

Jeg er ikke uenig med Dan (selv om et bedre valg kan bare være ikke å svare) ... men ...

Enhetstesting er prosessen med å skrive kode for å teste atferd og funksjonaliteten til systemet.

Tydeligvis tester forbedre kvaliteten på koden din, men det er bare en overfladisk fordel for enhetstesting. De virkelige fordelene er å:

  1. Gjør det enklere å endre den tekniske gjennomføringen samtidig som at du ikke endrer atferd (refactoring). Riktig enhet testet koden kan aggressivt refactored / ryddet opp med liten sjanse til å bryte noe uten å merke det.
  2. Gi utviklere tillit når du legger atferd eller gjøre reparasjoner.
  3. Dokumentere koden din
  4. Indikerer områder av koden som er tett koblet. Det er vanskelig å enhet test kode som er tett koblet
  5. Et middel for å bruke API og søke etter problemer tidlig
  6. Indikerer metoder og klasser som ikke er veldig sammenhengende

Du bør enhet test fordi det i din interesse å levere en vedlikeholdsvennlig og kvalitet produktet til kunden.

Jeg foreslår at du bruker det for ethvert system, eller en del av et system, hvilke modeller virkelige verden oppførsel. Med andre ord, det er spesielt godt egnet for bedriftsutvikling. Jeg ville ikke bruke den for Engangs / hjelpeprogrammer. Jeg ville ikke bruke den for deler av et system som er problematisk å test (UI er et vanlig eksempel, men det er ikke alltid tilfelle)

Den største fallgruve er at utviklere teste for stor enhet, eller de anser en metode en enhet. Dette gjelder særlig hvis du ikke forstår Inversjon av kontroll - i så fall din enhet tester vil alltid slå til ende-til-ende-integrasjonstesting. Unit test bør teste individuelle atferd - og de fleste metoder har mange atferd.

Den største misforståelsen er at programmerere ikke bør teste. Bare dårlige eller late programmerere tro det. Skulle fyren bygge taket ikke teste det? Dersom legen erstatte en hjerteklaff ikke teste den nye ventilen? Bare en programmerer kan teste at hans koden gjør hva han aktet å gjøre (QA kan teste edge tilfeller - hvor kode oppfører seg når den er fortalt å gjøre ting programmereren ikke har tenkt, og kunden kan gjøre akseptansetest - gjør koden gjøre hva hva kunden har betalt for det å gjøre)

Svarte 04/08/2008 kl. 16:41
kilden bruker

stemmer
41

Den viktigste forskjellen på enhetstesting, i motsetning til "nettopp åpne en ny prosjekt og teste dette spesifikke koden" er at den er automatisert , og dermed repeterbart .

Hvis du teste koden manuelt, kan det overbevise deg om at koden fungerer perfekt - i sin nåværende tilstand . Men hva om en uke senere, når du har gjort en liten endring i den? Er du villig til å teste den igjen for hånd når noe endringer i koden din? Mest sannsynlig ikke :-(

Men hvis du kan kjøre tester når som helst, med ett enkelt klikk, akkurat på samme måte, i løpet av få sekunder , så de vil vise deg umiddelbart når noe er ødelagt. Og hvis du også integrere enheten testene i din automatisert byggeprosessen, vil de varsle deg om bugs selv i tilfeller der en tilsynelatende fullstendig irrelevant endring brøt noe i en fjern del av kodebasen - når det ikke engang ville skje med deg at det er et behov for å teste den aktuelle funksjonaliteten.

Dette er den største fordelen med enhet tester overlevere testing. Men vent, det er mer:

  • enhet tester forkorte utviklingen feedback loop dramatisk: med en separat testing avdeling kan det ta uker for deg å vite at det er en feil i koden din, da du allerede har glemt mye av konteksten, og dermed kan det ta deg timer å finne og rette opp en feil; OTOH med enhet tester, er tilbakemeldingene syklus målt i sekunder, og bug fix prosessen er vanligvis langs linjene av en "oh sh * t, jeg glemte å se etter at tilstanden her" :-)
  • enhet tester effektivt dokumentere (din forståelse av) atferden til koden din
  • enhetstesting tvinger deg til å revurdere dine design valg, noe som resulterer i enklere, renere utforming

Unit testing rammer i sin tur gjør det enkelt for deg å skrive og kjøre testene.

Svarte 14/03/2010 kl. 17:20
kilden bruker

stemmer
31

Jeg ble aldri lært enhetstesting på universitetet, og det tok meg en stund å "få" det. Jeg leste om det, gikk "ah, ikke sant, automatisert testing, som kan være kult jeg tror", og jeg glemte det.

Det tok ganske mye lenger før jeg virkelig funnet ut poenget: La oss si at du jobber på et stort system, og du skriver en liten modul. Det kompilerer, du setter den gjennom sine skritt, det fungerer bra, du går videre til neste oppgave. Ni måneder ned linjen og to versjoner senere noen andre gjør en endring til noen tilsynelatende urelaterte del av programmet, og det bryter modulen. Verre, tester de sine endringer, og deres koden fungerer, men de trenger ikke teste modul; helvete, kan de ikke engang vet modulen finnes .

Og nå har du fått et problem: brutt kode er i bagasjerommet, og ingen vet enda. Den beste fall er en intern tester finner det før du skipet, men fikse kode som sent i spillet er dyrt. Og hvis ingen intern tester finner det ... vel, det kan bli veldig dyrt faktisk.

Løsningen er enhetstester. De vil fange opp problemer når du skriver kode - som er greit - men du kunne ha gjort det for hånd. Den virkelige Utbetalingen er at de vil fange problemer ni måneder ned linjen når du arbeider nå med et helt annet prosjekt, men summer intern mener det vil se ryddigere hvis disse parametrene var i alfabetisk rekkefølge - og deretter enheten testen du skrev vei tilbake mislykkes, og noen kaster ting på lærling før han endrer parameteren ordren tilbake. Det er de "hvorfor" av enhet tester. :-)

Svarte 19/09/2008 kl. 12:45
kilden bruker

stemmer
13

Chipping inn på de filosofiske argumenter for enhetstesting og TDD her er noen av de viktige "lightbulb" observasjoner som slo meg på min forsiktige første skritt på veien til TDD opplysning (ingen original eller nødvendigvis nyheter) ...

  1. TDD betyr ikke skrive dobbelt så mye kode. Test kode er vanligvis ganske rask og smertefri å skrive og er en viktig del av designprosessen og kritisk.

  2. TDD hjelper deg til å innse når du skal stoppe koding! Testene gi deg tillit til at du har gjort nok for nå, og kan stoppe tweaking og gå videre til neste ting.

  3. Testene og koden arbeide sammen for å oppnå bedre kode. Koden kan være dårlig / buggy. Din TEST kan være dårlig / buggy. I TDD er du banktjenester på sjansene for BÅDE å være dårlig / buggy være ganske lav. Ofte sin test som trenger å fikse, men det er fortsatt et godt resultat.

  4. TDD hjelper med koding forstoppelse. Du vet den følelsen at du har så mye å gjøre at du knapt vet hvor du skal begynne? Det er fredag ​​ettermiddag, hvis du bare utsette for et par flere timer ... TDD kan du kjøttet ut svært raskt hva du tror du trenger å gjøre, og får koding beveger seg raskt. Også, som lab rotter, tror jeg vi alle svare på det store grønt lys og jobbe hardere for å se det igjen!

  5. På samme måte, kan disse designer typer se hva de jobber med. De kan vandre av for en juice / sigarett / iphone pause og gå tilbake til en skjerm som umiddelbart gir dem et visuelt med hensyn til hvor de kom til. TDD gir oss noe lignende. Det er lettere å se hvor vi fikk når livet griper ...

  6. Jeg tror det var Fowler som sa: "Imperfect tester, kjører ofte, er mye bedre enn perfekt tester som aldri blir skrevet i det hele tatt". Jeg tolker dette som gir meg tillatelse til å skrive tester hvor jeg tror de vil være mest nyttig, selv om resten av mitt kodedekning er sørgelig mangelfull.

  7. TDD hjelper i alle slags overraskende måter ned linjen. Gode ​​enhet tester kan hjelpe dokument hva noe er ment å gjøre, kan de hjelpe deg med å overføre koden fra ett prosjekt til et annet, og gi deg en uberettiget følelse av overlegenhet over din ikke-testing kolleger :)

Denne presentasjonen er en utmerket introduksjon til alle yummy godhet testing innebærer.

Svarte 24/08/2008 kl. 21:58
kilden bruker

stemmer
7

Jeg ønsker å anbefale xUnit Testing Oppskrifter bok av Gerard Meszaros. Det er store, men er en stor ressurs på enhetstesting. Her er en link til sin nettside der han diskuterer det grunnleggende enhetstesting. http://xunitpatterns.com/XUnitBasics.html

Svarte 14/03/2010 kl. 18:10
kilden bruker

stemmer
5

Jeg bruker enhet tester for å spare tid.

Når du bygger forretningslogikk (eller datatilgang) testing funksjonalitet kan ofte innebære å skrive ting inn i en masse skjermer som kan eller ikke kan være ferdig enda. Automatisering av disse testene sparer tid.

For meg enhet tester er en slags modularisert test sele. Det er vanligvis minst en test per offentlig funksjon. Jeg skriver flere tester for å dekke ulike atferd.

Alle de spesielle tilfeller at du tenkte på når du utvikler koden kan tas opp i koden i enheten testene. Enheten testene også bli en kilde til eksempler på hvordan du bruker koden.

Det er mye raskere for meg å oppdage at min nye koden bryter noe i min enhet tester deretter å sjekke inn koden og har noen front-end utvikler finne et problem.

For datatilgang testing jeg prøver å skrive tester som enten har ingen endring eller rydde opp etter seg.

Enhet tester kommer ikke til å være i stand til å løse alle testkrav. De vil være i stand til å spare utviklingstid og test kjernen deler av programmet.

Svarte 17/09/2008 kl. 00:38
kilden bruker

stemmer
5

Dette er min ta på den. Jeg vil si enhetstesting er praksisen med å skrive programvare tester for å bekrefte at ekte programvare gjør det den er ment for. Dette startet med JUnit i Java verden og har blitt en beste praksis i PHP samt med SimpleTest og PHPUnit . Det er en kjerne praksis med Extreme Programming og hjelper deg å være sikker på at programvaren fortsatt fungerer som forutsatt etter redigering. Hvis du har nok testdekning, kan du gjøre store refactoring, feilretting eller legge til funksjoner raskt med mye mindre frykt for å introdusere andre problemer.

Det er mest effektivt når alle enhet tester kan kjøres automatisk.

Enhetstesting er vanligvis forbundet med OO utvikling. Den grunnleggende ideen er å lage et skript som setter opp miljøet for koden og deretter øvelser den; du skriver påstander, angi den tiltenkte produksjonen som du skal motta og deretter utføre testen script ved hjelp av et rammeverk som nevnt ovenfor.

Rammeverket vil kjøre alle testene mot koden og deretter rapportere tilbake suksess eller fiasko for hver test. PHPUnit kjøres fra Linux kommandolinjen som standard, selv om det er HTTP-grensesnitt tilgjengelig for det. SimpleTest er nettbasert av natur, og er mye lettere å komme i gang, IMO. I kombinasjon med xDebug kan PHPUnit gi deg automatiserte statistikk for kodedekning som noen mennesker finner svært nyttig.

Noen lag skrive kroker fra deres Subversion slik at enheten tester kjøres automatisk når du begår endringer.

Det er god praksis å holde enheten tester i samme depot som søknaden din.

Svarte 04/08/2008 kl. 23:53
kilden bruker

stemmer
4

Bibliotekene som NUnit , xUnit eller JUnit er bare obligatorisk hvis du ønsker å utvikle dine prosjekter ved hjelp av TDD tilnærming popularisert av Kent Beck:

Du kan lese Introduksjon til testdrevet utvikling (TDD) eller Kent Beck bok Test Driven Development: By Eksempel .

Så, hvis du ønsker å være sikker på at testene dekke en "god" delen av koden din, kan du bruke programvare som NCover , JCover , PartCover eller hva. De vil fortelle deg dekning prosentandel av koden din. Avhengig av hvor mye du er flink til å TDD, vil du vite om du har praktisert det godt nok :)

Svarte 14/03/2010 kl. 17:22
kilden bruker

stemmer
3

Jeg tror det punktet at du ikke forstår er at enheten testing rammeverk som NUnit (og lignende) vil hjelpe deg i å automatisere små og mellomstore tester. Vanligvis kan du kjøre testene i et GUI (som er tilfellet med NUnit , for eksempel) ved å klikke på en knapp og deretter - forhåpentligvis - se fremdriftslinjen bli grønn. Hvis den blir rød, viser rammene du hvilken test mislyktes og hva som gikk galt. I en normal enhet test, du bruker ofte påstander, for eksempel Assert.AreEqual(expectedValue, actualValue, "some description")- så hvis de to verdiene er ulike, vil du se en feilmelding som sier "noen beskrivelse: forventet <expectedValue> men var <actualValue>".

Så som en konklusjon enhetstesting vil gjøre testing raskere og mye mer behagelig for utviklere. Du kan kjøre alle enheten testene før du forplikter deg ny kode, slik at du ikke bryter byggeprosessen av andre utviklere på samme prosjekt.

Svarte 14/03/2010 kl. 17:25
kilden bruker

stemmer
3

Enhetstesting er en praksis å sørge for at funksjonen eller modul som du kommer til å implementere kommer til å oppføre seg som forventet (krav) og også å sørge for hvordan den oppfører seg i situasjoner som grensebetingelser og ugyldige inndata.

xUnit , NUnit , mbUnit , etc. er verktøy som hjelper deg i å skrive testene.

Svarte 14/03/2010 kl. 17:22
kilden bruker

stemmer
3

Enhetstesting er i ferd med å skrive kode som tester din applikasjonskode.

Den Unit del av navnet er om den intensjon å teste små enheter med kode (en metode for eksempel) på en gang.

xUnit er der for å hjelpe til med denne testingen - de er rammeverk som hjelper med dette. En del av det er automatisert testløpere som forteller deg hva testen mislykkes, og hvilke som passerer.

De har også fasiliteter for å sette opp felles kode som du trenger i hver test før hånd og rive det ned når alle testene er fullført.

Du kan ha en test for å sjekke at en forventet unntak har blitt kastet, uten å måtte skrive hele prøve fangst blokkere deg selv.

Svarte 14/03/2010 kl. 17:19
kilden bruker

stemmer
3

Bruk Testivus . Alt du trenger å vite er rett der :)

Svarte 17/09/2008 kl. 00:48
kilden bruker

stemmer
2

Først av alt, enten vi snakker om Unit testing eller andre typer automatisert testing (Integration, Load, UI testing etc.) er den største forskjellen fra det du antyder at det er automatisert, repeterbare og det krever ingen menneskelige ressurser å bli fortært (= ingen har å utføre testene, de vanligvis kjøre på et trykk på en knapp).

Svarte 14/03/2010 kl. 17:22
kilden bruker

stemmer
2

Test Driven Development har liksom tatt over begrepet Unit Test. Som en gammel tidtaker vil jeg nevne mer generell definisjon av det.

Enhet Test betyr også testing av en enkelt komponent i et større system. Dette enkelt komponent kan være en dll, exe, klassebibliotek, etc. Det kan også være et enkelt system i en multi-system søknad. Så til slutt Unit Test ender opp med å bli testing av hva du vil kalle et enkelt stykke av et større system.

Du vil da gå opp til integrert eller systemtesting ved å teste hvordan alle komponentene fungerer sammen.

Svarte 24/08/2008 kl. 22:34
kilden bruker

stemmer
2

Enhet-testing er testing av en enhet med kode (for eksempel en enkelt funksjon) uten behov for infrastruktur som den enhet av koden er avhengig av. dvs. teste den i isolasjon.

Hvis for eksempel den funksjonen du tester kobles til en database og gjør en oppdatering, i en enhet test du kanskje ikke ønsker å gjøre det oppdatering. Du ville om det var en integrasjonstest, men i dette tilfellet er det ikke.

Så en enhet test ville utøve funksjonaliteten vedlagt i "-funksjonen" du tester uten bivirkninger av databaseoppdatering.

Si din funksjon hentet noen tall fra en database og deretter utført en standardavvik beregning. Hva er det du prøver å teste her? At standardavviket beregnes riktig eller at dataene er returnert fra databasen?

I en enhet test du bare ønsker å teste at standardavviket beregnes riktig. I en integrasjonstest vil du teste standardavviket beregning og databasen henting.

Svarte 15/08/2008 kl. 17:42
kilden bruker

stemmer
1

Dette svarer til hvorfor du bør gjøre enhetstesting.


De 3 videoer nedenfor dekker enhetstesting i javascript, men de generelle prinsippene gjelder på tvers av de fleste språk.

Unit Testing: Minutter Nå vil spare timer senere - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

JS Unit Testing (veldig bra) - https://www.youtube.com/watch?v=-IYqgx8JxlU

Skrive Målbare Java - https://www.youtube.com/watch?v=OzjogCFO4Zo


Nå er jeg bare lære om emnet, så jeg kan ikke være 100% korrekt, og det er mer til det enn det jeg beskriver her, men min grunnleggende forståelse av enhetstesting er at du skriver noen test kode (som holdes atskilt fra hoved~~POS=TRUNC kode) som kaller en funksjon i hoved kode med innspill (argumenter) at funksjonen krever og koden sjekker da om det blir tilbake en gyldig returverdi. Hvis det ikke kommer tilbake en gyldig verdi enheten testing rammeverk som du bruker til å kjøre testene viser en grønn lys (alt bra) hvis verdien er ugyldig du får et rødt lys, og du deretter kan løse problemet med en gang før du slipper den nye koden til produksjon, uten å teste kan du faktisk ikke har fanget opp feilen.

Så du skrive tester for deg gjeldende kode og lage koden slik at den passerer testen. Måneder senere du eller noen andre behov for å endre funksjonen i hovedkoden, fordi tidligere du hadde allerede skrevet test koden for den funksjonen du nå kjøre igjen, og testen kan mislykkes fordi koder innført en logisk feil i funksjonen eller returnere noe helt annerledes enn hva den funksjonen er ment å gå tilbake. Igjen uten å prøve i stedet kan være at feilen vanskelig å spore opp som det kan muligens påvirke annen kode i tillegg, og vil gå ubemerket hen.


Også det faktum at du har et dataprogram som går gjennom koden og tester den i stedet for at du manuelt gjøre det i nettleseren side for side sparer tid (enhetstesting for javascript). La oss si at du endre en funksjon som brukes av noen skript på en nettside og det fungerer vel og bra for sin nye formål. Men, la oss også si for argumenter skyld at det er en annen funksjon du har et annet sted i koden som er avhengig av at nylig endret funksjon for å fungere ordentlig. Dette avhenger funksjonen kan nå slutte å virke på grunn av endringene du har gjort i den første funksjonen, men uten tester på plass som kjøres automatisk av datamaskinen din, vil du ikke merke at det er et problem med denne funksjonen før det faktisk er utført og du må navigere manuelt til en nettside som inneholder script som utfører den avhengige funksjon, bare så du merker at det er en feil på grunn av endringen du gjorde til den første funksjonen.

For å gjenta, har tester som kjøres samtidig utvikle din søknad vil fange disse typer problemer som du koder. Ikke å ha testene i stedet du måtte gå manuelt gjennom hele programmet, og selv da kan det være vanskelig å få øye på bug, naivt du sender det ut i produksjon, og etter en stund en slags bruker sender du en feilrapport (som vil ikke være like god som dine feilmeldinger i en testing rammeverk).


Det er ganske forvirrende når du først høre av emnet og du tenker for deg selv, er jeg ikke allerede teste koden min? Og koden du har skrevet virker som det er ment å allerede, "Hvorfor trenger jeg et annet rammeverk?" ... Ja du allerede teste koden din, men en datamaskin er bedre på å gjøre det. Du trenger bare å skrive gode nok tester for en funksjon / enhet av koden en gang og resten er tatt vare på for deg av den mektige cpu i stedet for at du må sjekke manuelt at alle koden din er fremdeles arbeider når du gjør en endring i koden din.

Dessuten trenger du ikke å enhet teste koden din hvis du ikke vil, men det lønner seg som prosjekt / kodebasen begynner å vokse seg større som sjansene for å innføre bugs øker.

Svarte 18/07/2015 kl. 18:34
kilden bruker

stemmer
1

Hva gjør du hvis du får en haug med dritt og ser ut som om du står fast i en evig tilstand av opprydding som du vet med tillegg av noen ny funksjon eller kode kan bryte gjeldende sett fordi den nåværende programvaren er som et hus kort?

Hvordan kan vi gjøre enhetstesting da?

Du begynner i det små. Prosjektet jeg kom akkurat inn hadde ingen enhetstesting før et par måneder siden. Når dekningen var at lav, ville vi bare plukke en fil som ikke hadde dekning, og klikk "legg tester".

Akkurat nå er vi opp til over 40%, og vi har klart å plukke av de fleste av de lavthengende frukt.

(Det beste er at selv på dette lave nivået av dekning, har vi allerede kjørt inn mange tilfeller av koden gjør gale ting, og testing fanget den. Det er en stor motivator for å presse folk til å legge til mer testing.)

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

stemmer
1

Jeg gikk til en presentasjon om enhetstesting på FoxForward 2007 og ble aldri fortalt til enheten test noe som fungerer med data. Tross alt, hvis du tester på live data, resultatene er uforutsigbare, og hvis du ikke tester på live data, er du faktisk ikke teste koden du skrev. Dessverre er det meste av koding jeg gjør i disse dager. :-)

Jeg tok en sjanse på TDD nylig da jeg skrev en rutine for å lagre og gjenopprette innstillinger. Først, bekreftet jeg at jeg kunne lage lagringsobjekt. Da, at det hadde den metoden jeg trengte å ringe. Da, at jeg kan kalle det. Da, at jeg kunne passere det parametere. Da, at jeg kunne passere det bestemte parametere. Og så videre, helt til jeg ble endelig bekrefte at det ville redde den angitte innstillingen, tillate meg å endre det, og deretter gjenopprette den, for flere forskjellige syntakser.

Jeg fikk ikke komme til slutten, fordi jeg trengte-the-rutine nå-faen, men det var en god øvelse.

Svarte 22/08/2008 kl. 18:10
kilden bruker

stemmer
0

Unit-testing og TDD generelt gjør at du kan ha kortere tilbakemeldinger sykluser om programvaren du skriver. I stedet for å ha en stor testfase på slutten av gjennomføringen, du gradvis teste alt du skriver. Dette øker kodekvalitet veldig mye, som du umiddelbart se, hvor du kan ha bugs.

Svarte 03/05/2017 kl. 09:33
kilden bruker

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