Innholdsfortegnelse
Når vi gjør store utbygginger, mister vi ofte synet på når vi gjør en endring i at det vil påvirke resten av det, denne typen usikkerhet kan føre til katastrofe hvis de nye endringene virkelig skader noe som tidligere ble godkjent.For å unngå denne typen situasjoner er utvikling basert på tester, det vil si at vi bygger systemtester Før vi bygger koden med løsningen, starter vi på denne måten med noe som gir oss feil fra begynnelsen, og vi får den til å bestå alle testene.
Når vi legger til en ny endring, kjører vi bare alle testene som allerede er skrevet, og hvis noen som allerede hadde bestått mislykkes, vet vi at vi må gjøre en korreksjon i koden vår.
Prøv først, kode senere
I programmeringsmetoden er det vanligvis det vi gjør skriv et stykke kode og senere prøv programmet vårt La oss se om den kjører og gir oss det forventede resultatet, mange kan si at dette er det beste og kanskje for visse krav det er det beste alternativet, men hva om vi med hver nye kode må prøve en hel shoppingprosess, der vi bruker 15 minutter bare å teste, ville dette være mye sløsing med tid vi kan bruke på å gjøre andre aktiviteter i prosjektet vårt.
I ekstrem programmering der vi må oppnå flotte resultater med et minimum av ressurser og tid, hvis vi forestiller oss den tidligere situasjonen, garanterer vi en viss feil, det er her programmering basert på tester eller Testdrevet utvikling Så mange ganger vi vil finne det, med dette vil vi først gjøre testen og deretter koden, og tvinge oss til å ha støtte med testen og dermed ha visshet om at koden vår ikke mislykkes, så til slutt i stedet for å teste en kjøpsprosessen vil vi ganske enkelt kjøre en fil som vil gi oss resultatet av sjekkpunkter som vi bestemmer oss for å prøve.
La oss se nedenfor et bilde med en kode som utfører noen tester, og så vil vi forklare hvordan det fungerer:
Hvis det er riktig, skriver vi ut at vi besto testen, ellers har testen mislyktes, denne ganske enkle tilnærmingen til hva en test er viser oss at mer enn å se om programmet vårt kjører eller ikke, leter vi etter en validering på løsningen vår på nivået Generelt, siden ved å vite hva vi må returnere, kjenner vi problemet, og med det må vi finne en måte å løse det på.
I eksempeltesten, hvis vi kjører den, må vi ha mange feil i begynnelsen, ettersom vi løser hver av dem, oppnår vi validering av løsningen vår.
Selv om det først ser ut til at vi programmerer omvendt, kan denne metoden på slutten av dagen spare oss for mye hodepine når vi gjør et stort og komplekst system.Likte og hjalp du denne opplæringen?Du kan belønne forfatteren ved å trykke på denne knappen for å gi ham et positivt poeng
