Wat is unit testen?

stemmen
193

Ik zag veel vragen te stellen 'hoe' om unit test in een bepaalde taal, maar er is geen vraag te vragen 'wat', 'waarom' en 'wanneer'.

  • Wat is het?
  • Wat betekent het voor mij doen?
  • Waarom zou ik het gebruiken?
  • Wanneer moet ik gebruiken (ook wanneer deze niet)?
  • Wat zijn enkele veel voorkomende valkuilen en misvattingen
De vraag is gesteld op 04/08/2008 om 17:27
bron van user
In andere talen...                            


20 antwoorden

stemmen
182

Unit testing is, grosso modo, het testen van stukjes code in isolatie, met test code. De directe voordelen die te binnen schieten zijn:

  • Uitvoeren van de test wordt automatiseren-staat en herhaalbare
  • U kunt testen op een veel gedetailleerder niveau dan point-and-click testing via een GUI

Merk op dat als je test code schrijft naar een bestand, opent een database-verbinding of iets doet over het netwerk, het is meer adequaat gecategoriseerd als een integratie test. Integratie testen zijn een goede zaak, maar moet niet worden verward met unit tests. Unit test code moet kort, lief en snel uit te voeren zijn.

Een andere manier om te kijken naar unit testing is dat je eerst schrijven de tests. Dit staat bekend als Test-Driven Development (TDD in het kort). TDD brengt bijkomende voordelen:

  • Je hoeft niet schrijven speculatieve "Ik kan dit in de toekomst nodig" code - net genoeg om de tests
  • De code die u hebt geschreven wordt altijd bedekt door middel van proeven
  • Door het schrijven van de test eerste, ben je gedwongen na te denken over hoe je de code, die meestal het ontwerp van de code op de lange termijn verbetert noemen.

Als je nu niet doet unit testing, raad ik u aan de slag op. Hier krijg je een goed boek, praktisch elke xUnit-boek zal doen, omdat de begrippen zijn zeer overdraagbaar tussen hen.

Soms is het schrijven van unit tests kan pijnlijk zijn. Wanneer het wordt op die manier, proberen om iemand om u te helpen, en de verleiding weerstaan ​​om "gewoon schrijven de verdomde code" te vinden. Unit testing is een partij als de afwas. Het is niet altijd aangenaam, maar het houdt uw metaforische keuken schoon, en je echt wilt het schoon. :)


Edit: Een misvatting in je opkomt, hoewel ik weet niet zeker of het zo vaak voor. Ik heb gehoord dat een project manager zeggen dat de unit tests maakte het team schrijft alle code tweemaal in. Als het eruit ziet en voelt op die manier, nou ja, je doet het verkeerd. Niet alleen het schrijven van de tests meestal versnellen van de ontwikkeling, maar het geeft je ook een handige "nu ik klaar ben" indicator die je anders niet zou hebben.

antwoordde op 04/08/2008 om 17:36
bron van user

stemmen
65

Ik ben het niet oneens met Dan (hoewel een betere keuze kan gewoon niet om te antwoorden) ... maar ...

Unit testing is het proces van het schrijven van code om het gedrag en de functionaliteit van uw systeem te testen.

Uiteraard toetst de kwaliteit van de code, maar dat is slechts een oppervlakkige voordeel van unit testing. De echte voordelen zijn:

  1. Maak het makkelijker om de technische implementatie te veranderen terwijl ervoor te zorgen dat je niet het gedrag (refactoring) te veranderen. De juiste unit getest code kan agressief worden herontworpen / opgeruimd met weinig kans op het breken van iets zonder het te merken.
  2. Geef ontwikkelaars vertrouwen bij het toevoegen van gedrag of het maken van fixes.
  3. Documenteer uw code
  4. Geef gebieden van uw code die nauw gekoppeld zijn. Het is moeilijk om unit test code die nauw is gekoppeld
  5. Een middel om uw API te gebruiken en zoeken naar problemen vroeg op
  6. Geeft methoden en klassen die niet erg samenhangend

Je moet unit test omdat het in uw belang om een ​​onderhoudbaar en kwaliteit van het product te leveren aan uw klant.

Ik stel voor dat u het voor een systeem, of een gedeelte van een systeem, welke modellen real-world gedrag. Met andere woorden, het is bijzonder goed geschikt voor de ontwikkeling van ondernemingen. Ik zou het niet gebruiken voor throw-away / hulpprogramma's. Ik zou het niet voor onderdelen van een systeem dat problematisch testen zijn (UI is een bekend voorbeeld, maar dat is niet altijd het geval)

De grootste valkuil is dat ontwikkelaars te testen te grote eenheid, of ze overwegen een methode een eenheid. Dit geldt met name als je niet begrijpt Inversion of Control - in dat geval zal uw unit tests altijd om te zetten in end-to-end integratie testen. Unit test moet individueel gedrag te testen - en de meeste methoden hebben vele gedrag.

De grootste misvatting is dat programmeurs niet moet testen. Alleen slecht of lui programmeurs geloven. Mocht de man het bouwen van uw dak het niet testen? Indien de arts het vervangen van een hartklep niet de nieuwe klep te testen? Alleen een programmeur kan testen dat zijn code doet wat hij van plan is te doen (QA kan testen extreme gevallen - hoe code zich gedraagt ​​wanneer het wordt verteld om dingen die de programmeur niet van plan was te doen, en de klant kan acceptatietest doen - doet de code te doen wat wat de klant betaald voor het te doen)

antwoordde op 04/08/2008 om 17:41
bron van user

stemmen
40

Het belangrijkste verschil unit testing, in tegenstelling tot "alleen het openen van een nieuw project en test deze specifieke code" is dat het geautomatiseerd , waardoor herhaalbaar .

Als u uw code handmatig te testen, kan het u te overtuigen dat de code perfect werkt - in zijn huidige staat . Maar wat te denken van een week later, wanneer je een kleine wijziging in het gemaakt? Bent u bereid om het weer opnieuw te testen met de hand wanneer er iets verandert in uw code? Waarschijnlijk niet :-(

Maar als je kunt de tests op elk gewenst moment te voeren, met een enkele klik, op precies dezelfde manier, binnen een paar seconden , dan zijn ze zullen u meteen zien wanneer er iets is gebroken. En als je ook de unit tests in uw geautomatiseerde bouwproces te integreren, zullen zij u te waarschuwen voor bugs zelfs in gevallen waarin een schijnbaar volledig los verandering brak iets in een afgelegen deel van de codebase - wanneer het zou niet eens bij je opgekomen dat er sprake is een nodig hebt om die bepaalde functionaliteit opnieuw te testen.

Dit is het belangrijkste voordeel van unit tests over hand testen. Maar wacht, er is meer:

  • unit tests verkorten van de ontwikkeling terugkoppeling dramatisch: met een aparte testafdeling te weken kan duren voor u om te weten dat er een bug in de code, tegen die tijd je al een groot deel van de context zijn vergeten, dus het kan je uren in beslag nemen vinden en oplossen van de bug; OTOH met unit tests, is de terugkoppelcyclus gemeten in seconden en het bug herstelproces is typisch langs de lijnen van een "oh sh * t, vergat om te controleren op voorwaarde dat hier" :-)
  • unit tests effectief documenteren (uw begrip van) het gedrag van uw code
  • unit testing dwingt je om uw ontwerp keuzes, wat resulteert in te herevalueren eenvoudiger, schoner ontwerp

Unit testing frameworks, op zijn beurt, maakt het gemakkelijk voor u om te schrijven en uitvoeren van de tests.

antwoordde op 14/03/2010 om 18:20
bron van user

stemmen
29

Ik was nooit geleerd unit testen op de universiteit, en het kostte me een tijdje om "get" het. Ik heb erover gelezen, ging "ah, rechts, geautomatiseerd testen, die kunnen koel denk ik zijn", en dan vergat ik erover.

Het duurde wat langer voordat ik echt dacht dat de punt: Laten we zeggen dat je werkt aan een groot systeem en schrijf je een kleine module. Het compileert, je hem aan de tand, het werkt geweldig, ga je door naar de volgende taak. Negen maanden langs de lijn en twee versies later iemand anders maakt een wijziging van een aantal ogenschijnlijk ongerelateerde onderdeel van het programma, en het breekt de module. Erger nog, ze testen hun veranderingen, en hun code werkt, maar ze niet de module te testen; hel, kunnen ze niet eens hoe je module bestaat .

En nu heb je een probleem: gebroken code is in de kofferbak en niemand weet zelfs. Het beste geval is een interne tester vindt het voor je schip, maar de vaststelling van code die laat in het spel is duur. En als er geen interne tester vindt het ... nou, dat kan inderdaad erg duur.

De oplossing unit tests. Ze zullen problemen op te vangen als je code te schrijven - en dat is prima - maar je had kunnen doen dat met de hand. De echte uitbetaling is dat ze problemen zullen vangen negen maanden langs de lijn als u nu werkt op een heel ander project, maar een zomer intern denkt het zal netter uitzien als die parameters waren in alfabetische volgorde - en dan is de unit test je schreef terugweg mislukt, en iemand gooit dingen op de stagiair, totdat hij de parameter bestelling terug verandert. Dat is het "waarom" van de unit tests. :-)

antwoordde op 19/09/2008 om 13:45
bron van user

stemmen
12

Chippen in op de filosofische voordelen van unit testen en TDD hier zijn een paar van deze toets "gloeilamp" opmerkingen die me opviel op mijn voorzichtige eerste stappen op weg naar TDD verlichting (geen origineel of noodzakelijkerwijs nieuws) ...

  1. TDD betekent NIET dat het schrijven van tweemaal de hoeveelheid code. Test code is meestal vrij snel en pijnloos te schrijven en is een belangrijk onderdeel van uw ontwerp proces en kritisch.

  2. TDD helpt u om te beseffen wanneer je moet stoppen codering! Uw test geeft je vertrouwen dat je genoeg voor nu heb gedaan en kan stoppen tweaken en ga naar de volgende zaak.

  3. De tests en de code werken samen om betere code te bereiken. Uw code kan slecht / buggy zijn. Uw TEST kon slecht / buggy zijn. In TDD u bankieren op de kansen van beide slecht zijn / buggy zijn vrij laag. Vaak zijn de test die vaststelling nodig heeft, maar dat is nog steeds een goed resultaat.

  4. TDD helpt bij het coderen van constipatie. Je weet dat gevoel dat je zoveel te doen je nauwelijks weet waar te beginnen? Het is vrijdagmiddag, als je gewoon uitstelgedrag voor een paar uur ... TDD kunt u heel snel wat je denkt dat je moet doen invulling te geven, en krijgt uw codering snel bewegen. Ook, net als lab ratten, ik denk dat we allemaal reageren op die grote groene licht en harder werken om het weer te zien!

  5. In dezelfde geest, kunnen deze ontwerper types zien wat ze mee bezig zijn. Ze kunnen dwalen af ​​voor een sap / sigaretten / iphone breken en terug te keren naar een monitor die onmiddellijk geeft hen een visuele aanwijzing over waar ze bij. TDD geeft ons iets dergelijks. Het is makkelijker om te zien waar we kregen als het leven ingrijpt ...

  6. Ik denk dat het was Fowler die zei: "Imperfect tests vaak lopen, zijn veel beter dan perfect tests die nooit helemaal worden geschreven". Ik interpreteren dit als het geven van me toestemming om tests waar ik denk dat ze het meest bruikbaar, zelfs als de rest van mijn code coverage is jammerlijk onvolledig zijn schrijven.

  7. TDD helpt bij allerlei verrassende manieren langs de lijn. Goede unit tests kunnen document wat iets moet doen te helpen, kunnen zij u helpen code migreren van het ene project naar het andere en geven u een onterechte gevoel van superioriteit ten opzichte van uw niet-test collega's :)

Deze presentatie is een uitstekende introductie tot al het lekkere goedheid testen met zich meebrengt.

antwoordde op 24/08/2008 om 22:58
bron van user

stemmen
7

Ik zou willen aanbevelen de xUnit Testing Patterns boek van Gerard Meszaros. Het is groot, maar is een geweldige bron op unit testing. Hier is een link naar zijn website waar hij bespreekt de basisprincipes van unit testing. http://xunitpatterns.com/XUnitBasics.html

antwoordde op 14/03/2010 om 19:10
bron van user

stemmen
5

Ik gebruik unit tests om tijd te besparen.

Bij het bouwen van business logica (of toegang tot de gegevens) testen functionaliteit kan vaak om te typen spullen in een heleboel schermen die al dan niet nog niet klaar. Het automatiseren van deze tests bespaart tijd.

Voor mij unit tests zijn een soort modulair testharnas. Er is meestal minstens één test per publieke functie. Ik schrijf aanvullende tests om verschillende gedragingen te dekken.

Alle speciale gevallen waarvan je dacht dat van bij het ontwikkelen van de code kan worden opgenomen in de code in de unit tests. De unit tests ook een bron van voorbeelden over hoe de code te worden.

Het is een stuk sneller voor mij om te ontdekken dat mijn nieuwe code breekt iets in mijn unit tests vervolgens in te checken in de code en hebben een aantal front-end developer het vinden van een probleem.

Voor toegang tot de gegevens testen probeer ik te testen die ofwel geen verandering of schoon te maken na zelf te schrijven.

Unit tests zijn niet van plan om in staat zijn om al het testen eisen op te lossen. Zij zullen in staat zijn om de ontwikkelingstijd en testkern delen van de applicatie op te slaan.

antwoordde op 17/09/2008 om 01:38
bron van user

stemmen
5

Dit is mijn overneemt het. Ik zou zeggen dat unit testing is de praktijk van het schrijven van software testen om te controleren of je echte software doet wat het is bedoeld. Dit begon met JUnit in de Java-wereld en is uitgegroeid tot een best practice in PHP als goed met SimpleTest en PHPUnit . Het is een kern praktijk van Extreme Programming en helpt u om er zeker van zijn dat uw software nog steeds werkt zoals bedoeld na het bewerken. Als u voldoende test dekking, kunt u grote refactoring, bug fixing doen of functies toe te voegen snel met veel minder angst voor de invoering van andere problemen.

Het is het meest effectief wanneer alle unit tests automatisch kunnen worden uitgevoerd.

Unit testing is algemeen geassocieerd met OO ontwikkeling. Het basisidee is om een ​​script waarin de omgeving voor uw code en dan oefent het te creëren; je schrijft beweringen, geeft u de beoogde output die je moet ontvangen en voer vervolgens uw test script met behulp van een kader zoals die hierboven vermeld.

Het kader zal alle tests tegen uw code uit te voeren en vervolgens verslag uit het succes of falen van elke test. PHPUnit wordt uitgevoerd vanaf de Linux command line standaard, maar er zijn HTTP interfaces beschikbaar voor is. SimpleTest is web-based door de natuur en is veel gemakkelijker om up and running te krijgen, IMO. In combinatie met xdebug, kunt PHPUnit u geautomatiseerde statistieken voor code coverage die sommige mensen vinden zeer nuttig te geven.

Sommige teams schrijven haken uit hun subversie repository zodat unit tests automatisch worden uitgevoerd wanneer u wijzigingen te plegen.

Het is een goede gewoonte om uw unit tests in dezelfde repository als uw aanvraag te houden.

antwoordde op 05/08/2008 om 00:53
bron van user

stemmen
4

Bibliotheken zoals NUnit , xUnit of JUnit zijn enkel verplicht als u wilt uw projecten met behulp van de ontwikkeling van TDD aanpak gepopulariseerd door Kent Beck:

U kunt lezen Inleiding tot Driven Development (TDD) Test of Kent Beck's boek Test Driven Development: door het goede voorbeeld .

Dan, als je zeker wilt zijn de tests hebben betrekking op een "goede" deel van de code, kunt u software gebruiken, zoals NCover , JCover , PartCover of wat dan ook. Ze zullen je vertellen het dekkingspercentage van je code. Afhankelijk van hoeveel je bedreven bent in TDD, dan weet je als je hebt geoefend het goed genoeg :)

antwoordde op 14/03/2010 om 18:22
bron van user

stemmen
3

Ik denk dat het punt dat je niet begrijpt is dat unit testing frameworks zoals NUnit (en dergelijke) die u zal helpen bij het automatiseren van kleine tot middelgrote testen. Meestal kunt u de tests in een GUI (dat is het geval met draaien NUnit , bijvoorbeeld) door simpelweg te klikken op een knop en dan - hopelijk - zie de voortgangsbalk groen blijven. Als het rood wordt, het kader laat u zien welke test is mislukt en wat er precies mis ging. In een normale unit test, gebruik je vaak beweringen, bijvoorbeeld Assert.AreEqual(expectedValue, actualValue, "some description")- dus als de twee waarden ongelijk ziet u een foutmelding "enkele beschrijving verwacht <expectedValue> maar was <actualValue>".

Dus als een conclusie unit testing sneller zal dergelijke testen en een stuk comfortabeler voor ontwikkelaars. U kunt alle unit tests de aanloop voor het plegen van nieuwe code, zodat je niet het bouwproces van andere ontwikkelaars te breken op hetzelfde project.

antwoordde op 14/03/2010 om 18:25
bron van user

stemmen
3

Unit testing is een praktijk om ervoor te zorgen dat de functie of de module die u gaat implementeren zich gaat gedragen zoals verwacht (requirements) en ook om ervoor te zorgen hoe het zich gedraagt ​​in scenario's zoals randvoorwaarden, en ongeldige invoer.

xUnit , NUnit , mbUnit , enz. zijn hulpmiddelen die u helpen bij het schrijven van de tests.

antwoordde op 14/03/2010 om 18:22
bron van user

stemmen
3

Unit testing is over het schrijven van code die je applicatie code testen.

De eenheid van de naam van het voornemen om kleine stukken code te testen (een werkwijze voor voorbeeld) per keer.

xUnit is er om te helpen met deze tests - ze zijn kaders die helpen met dit. Een deel van die geautomatiseerde test lopers die u vertellen wat test niet halen en welke passeren.

Ze hebben ook faciliteiten om setup gemeenschappelijke code die je nodig hebt in elke test voor de hand en scheur het neer als alle tests zijn afgerond.

U kunt een test om te controleren of een verwachte uitzondering is gegooid, zonder te schrijven de gehele try catch-blok zelf.

antwoordde op 14/03/2010 om 18:19
bron van user

stemmen
3

Gebruik Testivus . Alles wat je moet weten is daar :)

antwoordde op 17/09/2008 om 01:48
bron van user

stemmen
2

Allereerst, of spreken over Unit testing of andere vormen van geautomatiseerd testen (integratie, Load, UI testen etc.), het belangrijkste verschil van wat u voorstelt is dat het is geautomatiseerd, herhaalbaar en het heeft geen personele middelen nodig om te worden geconsumeerd (= niemand heeft om de tests uit te voeren, zijn ze meestal uitgevoerd bij een druk op de knop).

antwoordde op 14/03/2010 om 18:22
bron van user

stemmen
2

Test Driven Development is een soort van overgenomen de term Unit Test. Als een oude timer zal ik de meer algemene definitie van het te vermelden.

Eenheid testmiddel test ook een onderdeel van een groter systeem. Deze ene component zou een dll, exe, klasse bibliotheek, enz. Het kan zelfs een enkel systeem in een multi-systeem van toepassing zijn. Dus uiteindelijk eindigt Unit Test omhoog het zijn het testen van wat je wilt om een ​​enkel stuk van een groter systeem noemen.

U zou dan omhoog naar geïntegreerde of testen van het systeem door het testen van hoe alle onderdelen samen te werken.

antwoordde op 24/08/2008 om 23:34
bron van user

stemmen
2

Unit testen is het testen van een eenheid code (bijvoorbeeld een enkele functie) zonder dat de infrastructuur die deze eenheid code voert. dwz testen in isolatie.

Als, bijvoorbeeld, de functie die u test verbindt met een database en doet een update, in een unit test die u misschien niet zou willen die update te doen. Je zou als het ware een integratie test, maar in dit geval is het niet.

Dus een unit test zou de functionaliteit ingesloten in de "functie" u test zonder bijwerkingen van de database update uit te oefenen.

Stel dat uw functie opgehaald enkele cijfers uit een database en vervolgens uitgevoerd een standaarddeviatie berekening. Wat doe je hier probeer te testen? Dat de standaarddeviatie correct of dat de data wordt geretourneerd uit de database wordt berekend?

In een unit test wilt u gewoon om te testen of de standaarddeviatie correct is berekend. In een integratietest willen dat u de standaarddeviatie berekenen en de database retrieval te testen.

antwoordde op 15/08/2008 om 18:42
bron van user

stemmen
1

Dit geeft antwoord op waarom je zou moeten doen unit testing.


De 3 video hieronder deksel unit testing in javascript maar de algemene principes toe te passen in de meeste talen.

Unit Testing: Minuten Nu zal later bewaren Hours - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

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

Schrijven Testbare JavaScript - https://www.youtube.com/watch?v=OzjogCFO4Zo


Nu ben ik nog aan het leren over het onderwerp, zodat kan ik niet 100% correct te zijn en er is meer aan de hand dan wat ik hier beschrijven, maar mijn basiskennis van unit testing is dat u een aantal test code (die uit afzonderlijke wordt gehouden schrijf uw main code) die een functie oproepen in uw belangrijkste code met input (argumenten), die de functie vereist en de code controleert vervolgens of hij terug een geldige return waarde. Als het weer een geldige waarde van de unit testing framework dat u gebruikt om de tests uit te voeren toont een groen licht (allemaal goed) als de waarde ongeldig is krijg je een rood licht en je kunt dan is het probleem meteen voor je op te lossen laat de nieuwe code om de productie, zonder dat u op de proef kan zelfs niet de fout hebben gevangen.

Dus schrijf je tests voor je huidige code en maak de code, zodat deze voldoet aan de test. Maanden later u of iemand anders nodig om de functie in uw belangrijkste code te wijzigen, omdat eerder je had al geschreven test code voor die functie u nu opnieuw uit te voeren en de test kan mislukken omdat de coder introduceerde een logische fout in de functie of iets helemaal terug anders dan wat die functie wordt verondersteld om terug te keren. Opnieuw zonder de test in de plaats die fout kan moeilijk op te sporen omdat het mogelijk kan invloed hebben op andere code zo goed en zal onopgemerkt blijven.


Ook het feit dat je een computerprogramma dat via uw code wordt uitgevoerd en test in plaats van u dit handmatig doen in de browser pagina per pagina bespaart tijd (unit testing voor javascript). Laten we zeggen dat je een functie die wordt gebruikt door sommige script op een webpagina te wijzigen en het werkt allemaal goed en wel voor zijn nieuwe beoogde doel. Maar, laten we ook zeggen voor de argumenten wille dat er een andere functie moet je ergens anders in uw code die afhankelijk is van die onlangs gewijzigde functie nodig om goed te functioneren. Deze afhankelijke functie kan nu stoppen met werken als gevolg van de wijzigingen die u hebt aangebracht in de eerste functie, echter zonder testen in de plaats die automatisch worden uitgevoerd door de computer zal je niet merken dat er een probleem is met die functie, totdat het daadwerkelijk wordt uitgevoerd en je zult moeten handmatig naar een webpagina die het script dat de afhankelijke functie uitvoert omvat, alleen dan merk je dat er een bug als gevolg van de verandering die u hebt aangebracht in de eerste functie.

Nogmaals, met tests die worden uitgevoerd terwijl het ontwikkelen van uw aanvraag zal dit soort problemen op te vangen als je codering. Het niet hebben van de tests in de plaats zou je handmatig hoeft te gaan door je hele applicatie en zelfs dan kan het moeilijk zijn om de bug te herkennen, is het naïef om u uit in de productie en na een tijdje een soort gebruiker stuurt u een bug report (die zal niet zo goed als je foutmeldingen in een toetsingskader) zijn.


Het is nogal verwarrend wanneer je voor het eerst horen van het onderwerp en denk je bij jezelf, ik ben niet al het testen van mijn code? En de code die je hebt geschreven werkt zoals het hoort al: "waarom heb ik een ander kader nodig?" ... Ja, bent u al uw code te testen, maar een computer is beter te doen. Je moet gewoon goed genoeg testen eenmaal te schrijven voor een functie / eenheid van de code en de rest wordt verzorgd voor u genomen door de machtige cpu in plaats van dat u hoeft te handmatig controleren of alle van je code werkt nog steeds wanneer u een wijziging te maken jouw code.

Ook hoef je niet om het toestel te testen uw code als je niet wilt, maar het loont als uw project / code base begint te groter naarmate de kansen van de invoering van bugs toeneemt groeien.

antwoordde op 18/07/2015 om 18:34
bron van user

stemmen
1

Wat doe je als je een stapel onzin worden gegeven en lijkt alsof je vast zit in een voortdurende staat van opruimen die u met de toevoeging van een nieuwe functie of code kan de huidige set te breken omdat de huidige software is als een huis van kaarten?

Hoe kunnen we doen unit testen dan?

Je begint klein. Het project Ik ben net in had geen unit testing tot een paar maanden geleden. Wanneer de dekking was dat laag is, zouden we gewoon een bestand dat geen dekking had ophalen en klik op "testen toe te voegen".

Op dit moment zijn we tot meer dan 40%, en we zijn erin geslaagd om het grootste deel van het laaghangende fruit af te plukken.

(Het beste deel is dat zelfs bij deze lage niveau van dekking, hebben we al lopen in veel gevallen van de code het doen van de verkeerde dingen, en het testen ving hem. Dat is een enorme motivator om mensen te duwen om meer tests toe te voegen.)

antwoordde op 22/08/2008 om 19:19
bron van user

stemmen
1

Ik ging naar een presentatie over unit testen op FoxForward 2007 en werd nooit verteld om unit test iets dat werkt met gegevens. Immers, als je te testen op live data, de resultaten zijn onvoorspelbaar, en als je niet te testen op live data, je bent niet echt het testen van de code die je schreef. Helaas, dat is het grootste deel van de codering ik doe deze dagen. :-)

Ik heb neem een ​​schot op TDD onlangs toen ik aan het schrijven was een routine op te slaan en te herstellen instellingen. Ten eerste, ik vastgesteld dat ik de opslag object kan creëren. Dan, dat zij de methode die ik nodig had om te bellen. Dan, dat ik zou kunnen noemen. Dan, dat ik kon doorgeven parameters. Dan, dat ik kon doorgeven specifieke parameters. En zo verder, totdat ik werd uiteindelijk het verifiëren dat de opgegeven instelling zou redden, staat u mij om het te veranderen, en dan herstellen, voor verschillende syntaxis.

Ik heb niet tot het einde, want ik moest-the-routine-nu-dammit, maar het was een goede oefening.

antwoordde op 22/08/2008 om 19:10
bron van user

stemmen
0

Unit-testen en TDD in het algemeen kunt u kortere feedback cycli over de software die je schrijft te hebben. In plaats van het hebben van een grote testfase aan het einde van de uitvoering, u stapsgewijs te testen alles wat u schrijft. Dit verhoogt de kwaliteit van de code heel veel, zo zie je meteen waar je bugs zou kunnen hebben.

antwoordde op 03/05/2017 om 09:33
bron van user

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