Przeniesienie istniejącego kodu do Test Driven Development

Efektywna praca z kodem starszym jest moją Biblią, jeśli chodzi o migrację kodu bez testów do środowiska testowanego jednostkowo, a także zapewnia wiele wglądu w to, co sprawia, że kod jest łatwy do testowania i jak go testować.

Znalazłem również Test Driven Development na przykładzie i Pragmatic Unit Testing: in C# with NUnit jako przyzwoite wprowadzenie do testów jednostkowych w tym środowisku.

Jednym z prostych sposobów na rozpoczęcie TDD jest rozpoczęcie pisania testów najpierw od dziś i upewnij się, że za każdym razem, gdy musisz dotknąć istniejącego kodu (nie przetestowanego przez jednostkę), piszesz testy, które weryfikują istniejące zachowanie systemu, zanim go zmienisz, abyś mógł ponownie uruchomić te testy, aby zwiększyć pewność, że niczego nie zepsułeś.

Nazywam to "test Driven Reverse Engineering".

Zacznij "na dole" - każda klasa może być osobno zbadana i napisana dla niej test. W razie wątpliwości, zgaduj.

Kiedy wykonujesz zwykłe TDD w kierunku do przodu, traktujesz test jako święty i zakładasz, że kod jest prawdopodobnie złamany. Czasami test jest zły, ale twoja pozycja wyjściowa jest taka, że to kod.

Kiedy robisz TDRE, kod jest święty - dopóki nie udowodnisz, że kod ma długotrwały błąd. W odwrotnym przypadku, piszesz testy wokół kodu, poprawiając testy, dopóki nie zadziałają i twierdzisz, że kod działa.

Następnie, można kopać w złym kodzie. Niektórzy bad cade będą mieli sensowne przypadki testowe. trzeba to tylko posprzątać. Niektóre zły kod, jednak, będzie również przypadek testowy, który jest bezsensowny. Może to być błąd lub niezdarny projekt, który możesz naprawić.

Aby ocenić, czy kod jest rzeczywiście zły, należy również zacząć od top z ogólnymi przypadkami testowymi. Dane na żywo, które faktycznie działają, to początek. Również dane na żywo, które generują wszystkie znane błędy, również dobre miejsce na początek.

Napisałem małe generatory kodu, które zamieniają dane na żywo w unittest cases. W ten sposób mam spójne podstawy do testowania i refaktoryzacji.

Testowalny kod jest łatwy do wykrycia-przez towarzyszące testy. Jeśli są jakieś, muszą być testowalne. Jeśli ich nie ma-Załóżmy, że jest odwrotnie. ;)

To powiedziawszy: Test Driven Development (TDD) to nie tyle strategia testowania, co strategia projektowania. Testy, które piszesz, pomagają w zaprojektowaniu interfejsu Twoich klas, a także w poprawieniu zakresu Twoich klas (lub podsystemów w tym zakresie).

Mając testy, które stworzyłeś podczas TDD i wykonanie ich później czyni dobre testy, ale jest jedynie (bardzo mile widzianym) efektem ubocznym tej filozofii projektowania.

To powiedziawszy, spodziewaj się pewnego oporu ze strony kodu przed testowaniem. Posłuchaj kodu i zmień interfejs, aby był łatwy do przetestowania. Najprawdopodobniej przeprojektujesz go, gdy zaczniesz pisać testy.

Twój DLL zapewnia jakiś rodzaj usługi. Dla każdej usługi, co musisz zrobić przed otrzymaniem tej usługi, jakie parametry należy przekazać, aby uzyskać tę usługę, skąd możesz wiedzieć, że żądana usługa została poprawnie wykonana ?

Gdy już znajdziesz odpowiedzi na te pytania, możesz napisać pierwszy test. Takie testy byłyby raczej nazywane testami charakterystyki niż testami jednostkowymi, ale prawdopodobnie byłoby łatwiejsze do napisania niż testami jednostkowymi, gdyby biblioteka DLL nie była rozwijana korzystanie z TDD.

Testy Charakterystyki są również omówione w "Working Effectively with Legacy Code" M. Feathers, co jest zalecane w innych odpowiedziach.

Pamiętaj również, aby przed dodaniem nowej linii kodu napisać nieudany test.