<p>Postaram się przedstawić w kilku wpisach (w tej chwili szacuję, że to będą 3 lub 4 posty) podstawowe idee stojące za TDD. Nie zamierzam pisać tutaj kursu (btw: polecam wpisy na <a href="https://dariuszwozniak.net/2013/04/20/kurs-tdd-czesc-1-wstep/" target="_blank">blogu</a> Dariusza Woźniaka), ani kompleksowego opracowania – chodzi mi raczej o przystępne wprowadzenie do koncepcji, w taki sposób aby każdy mógł zacząć pisać najpierw testy a później właściwe funkcjonalności, czerpiąc z tego jak najwięcej korzyści :).</p>
<h2>Co to jest Test Driven Development?</h2>
<p>TDD, czyli programowanie sterowane testami to metodyka należąca do praktyk XP, polegająca na pisaniu testów jednostkowych przed pisaniem kodu produkcyjnego. Istotne jest zrozumienie, że głównym celem korzystania z TDD nie jest pokrycie kodu testami, a produkowanie kodu wysokiej jakości w oparciu o te testy.</p>
<h2>Po co mi to?</h2>
<p>Pisząc testy przed implementacją, najbardziej oczywistą zaletą jest pewność poprawności pisanego kodu (choć jasne jest, że testy nie chronią nas przed błędami w założeniach). Samo to, że kod jest pokryty testami, dobrze rokuje dla zmian w przyszłości ponieważ ktoś kto będzie zmuszony modyfikować nasz kod, ma możliwość zweryfikowania czy nic nie popsuł. Mniej oczywistym faktem jest to, że pisząc najpierw testy mimochodem piszemy lepszy kod – kod który jest testowalny to kod zwykle luźno powiązany, ze zredukowaną liczbą zależności.</p>
<h2>Wzorzec Red-Green-Refactor</h2>
<p>Główną osią wokół której obraca się TDD, jest postępowanie mogące skrótowo być opisane jako Red-Green-Refactor. Dlaczego? Pracując nad kodem postępujemy według instrukcji:</p>
<ol>
<li>Piszemy test dla nie istniejącej jeszcze funkcjonalności – test się załamie (Red).</li>
<li>Za wszelką cenę(wg. Kent’a Beck’a), nie bacząc na praktyki jeżeli rozwiązanie nie jest oczywiste, sprawiamy by test przeszedł. (Green)</li>
<li>Poprawiamy kod, spłacamy zaciągnięty (chwilkę wcześniej bo w punkcie 2) dług, staramy się by nasz kod był piękny i czytelny 😉 – cały czas dbając o zielony kolor wyniku testu.(Refactor).</li>
</ol>
<p>I tak, aż do momentu zakończenia pracy :).</p>
<h2>Wzorzec Arrange-Act-Assert</h2>
<p>Skoro jest o TDD, to mimochodem warto wspomnieć o wzorcu pisania testów jednostkowych. Już o nim pisałem więc zapraszam <a href="http://www.przemyslawowsianik.net/2016/02/24/testy-jednostkowe-wzorzec-aaa-lub-po-prostu-3a/" target="_blank">tutaj </a>:).</p>
<p>Testy a solucja:Na zakończenie tego wstępu istotna kwestia dotycząca izolacji testów jednostkowych: Odpowiednim miejscem umiejscowienia testów będzie po prostu nowy projekt. W sytuacji gdy w solucji mamy wiele projektów, dla każdego z nich powinien istnieć odpowiadający mu projekt z testami.</p>
<p>Przedstawiłem tutaj kilka podstawowych kwestii, w kolejnej części weźmiemy na warsztat prosty przykład, gdzie zbudujemy jakąś funkcjonalność od początku do końca podążając ścieżką TDD… 🙂</p>