Spisie treści
Kiedy dokonujemy zmian na dużą skalę, często tracimy z oczu, kiedy wprowadzamy zmianę, która wpłynie na resztę. Ten rodzaj niepewności może prowadzić do katastrofy, jeśli nowe zmiany naprawdę niszczą coś, co zostało wcześniej zatwierdzone.Aby uniknąć tego typu sytuacji, rozwój opiera się na testach, czyli budujemy testy systemowe Zanim zbudujemy kod z rozwiązaniem, w ten sposób zaczynamy od czegoś, co od początku daje nam błędy i sprawiamy, że przejdzie wszystkie testy.
Gdy dodajemy nową zmianę, po prostu uruchamiamy wszystkie napisane już testy, a jeśli któryś z tych, które już przeszły, nie powiodą się, wiemy, że musimy wprowadzić poprawkę w naszym kodzie.
Najpierw spróbuj, kod później
W podejściu programistycznym zwykle robimy: napisz kawałek kodu i później wypróbuj nasz program Zobaczmy, czy działa i daje oczekiwany efekt, wielu mogłoby powiedzieć, że jest to najlepsze i być może przy pewnych wymaganiach jest to najlepsza opcja, ale co jeśli z każdym nowym kodem musimy wypróbować cały proces zakupowy, w którym wydajemy 15 minut samego testowania, to byłaby duża strata czasu, którą moglibyśmy poświęcić na inne działania naszego projektu.
W programowaniu ekstremalnym, gdzie musimy osiągnąć świetne wyniki przy minimalnych zasobach i czasie, jeśli wyobrażamy sobie poprzednią sytuację, gwarantujemy pewną porażkę, to właśnie tam programowanie oparte na testach lub Rozwój oparty na testach Ile razy go znajdziemy, to z tym najpierw zrobimy test, a potem kod, zmuszając nas do posiadania wsparcia z testem i tym samym pewności, że nasz kod nie zawiedzie, a na końcu zamiast testowania proces zakupu po prostu uruchomimy plik, który poda nam wynik punkty kontrolne że postanawiamy spróbować.
Zobaczmy poniżej obrazek z kodem, który wykonuje kilka testów, a następnie wyjaśnimy, jak to działa:
Jeśli jest poprawny, wypisujemy, że zdaliśmy test, w przeciwnym razie test się nie powiódł, to dość proste podejście do tego, czym jest test, pokazuje nam, że bardziej niż sprawdzanie, czy nasz program działa, czy nie, szukamy walidacji naszego rozwiązania pod adresem poziom Generalnie, ponieważ wiedząc, co musimy zwrócić, znamy problem, a wraz z nim musimy znaleźć sposób na jego rozwiązanie.
W przykładowym teście, jeśli go uruchomimy, na początku musimy mieć wiele błędów, ponieważ rozwiązujemy każdy z nich, osiągamy walidację naszego rozwiązania.
Chociaż na początku wydaje się, że programujemy na odwrót, ostatecznie ta metodologia może oszczędzić nam wielu bólów głowy, gdy robimy duży i złożony system.Podobał Ci się i pomógł ten samouczek?Możesz nagrodzić autora, naciskając ten przycisk, aby dać mu pozytywny punkt
