Czy powielony kod jest bardziej tolerowany w testach jednostkowych?

Czytelność jest ważniejsza w testach. Jeśli test się nie powiedzie, chcesz, aby problem był oczywisty. Programista nie powinien przedzierać się przez wiele mocno uwzględnionych kodów testowych, aby dokładnie określić, co się nie udało. Nie chcesz, aby Twój kod testowy stał się tak złożony, że musisz napisać unit-test-tests.

Jednak wyeliminowanie duplikacji jest zazwyczaj dobrą rzeczą, o ile nic nie zasłania, a wyeliminowanie duplikacji w testach może prowadzić do lepszego API. Just upewnij się, że nie przekroczysz punktu malejących zwrotów.

Kod implementacji i testy to różne zwierzęta, a Zasady faktoringu stosują się do nich inaczej.

Zduplikowany kod lub struktura jest zawsze zapachem w kodzie implementacji. Kiedy zaczniesz mieć boilerplate w implementacji, musisz zmienić swoje abstrakcje.

Z drugiej strony, kod testowy musi utrzymywać poziom duplikacji. Powielanie w kodzie testowym osiąga dwa cele:

• trzymanie testów odsprzęgniętych. Nadmierne sprzężenie testowe może utrudnić zmianę jeden nieudany test, który wymaga aktualizacji, ponieważ kontrakt się zmienił.
• utrzymywanie znaczenia testów w izolacji. Gdy pojedynczy test zawodzi, musi być dość proste, aby dowiedzieć się dokładnie, co to jest testowanie.

Mam tendencję do ignorowania trywialnego powielania w kodzie testowym, o ile każda metoda testowa pozostaje krótsza niż około 20 linii. Lubię, gdy rytm setup-run-verify jest widoczny w metodach testowych.

Gdy duplikacja skrada się w części "verify" z testów często korzystne jest zdefiniowanie niestandardowych metod twierdzenia. Oczywiście metody te muszą nadal testować jasno określoną relację, która może być widoczna w nazwie metody: assertPegFitsInHole - > good, assertPegIsGood - > bad.

Gdy metody testowe stają się długie i powtarzalne, czasami uważam, że przydatne jest zdefiniowanie szablonów testów wypełniających puste pola, które przyjmują kilka parametrów. Następnie rzeczywiste metody testowe są zredukowane do wywołania metody szablonowej z odpowiednimi parametrami.

Jak na wiele z rzeczy w programowaniu i testowaniu, nie ma jasnej odpowiedzi. Musisz wyrobić sobie smak, a najlepszym sposobem na to jest popełnianie błędów.

Można zredukować powtarzanie za pomocą kilku różnych smaków metod testowych .

Jestem bardziej tolerancyjny na powtarzanie w kodzie testowym niż w kodzie produkcyjnym, ale czasami mnie to frustruje. Kiedy zmieniasz projekt klasy i musisz wrócić i dostosować 10 różnych metod testowania, wszystkie wykonują te same kroki konfiguracji, jest to frustrujące.

Zgadzam się. Handel istnieje, ale jest inny w różnych miejscach.

Jestem bardziej skłonny do refakturowania zduplikowanego kodu do Ustawienia stanu. Ale mniej prawdopodobne, aby refakturować część testu, która faktycznie ćwiczy kod. To powiedziawszy, jeśli ćwiczenie kodu zawsze zajmuje kilka linijek kodu, to mogę pomyśleć, że jest to zapach i refaktor rzeczywisty kod testowany. A to poprawi czytelność i konserwację zarówno kodu, jak i testów.

Jay Fields ukuł zdanie, że "DSLs powinny być wilgotne, a NIE suche", gdzie DAMP oznacza opisowe i znaczące zwroty . Myślę, że to samo dotyczy również testów. Oczywiście zbyt duże powielanie jest złe. Ale usuwanie duplikacji za wszelką cenę jest jeszcze gorsze. Testy powinny działać jako specyfikacje ujawniające intencje. Jeśli na przykład podasz tę samą funkcję pod kilkoma różnymi kątami, należy spodziewać się pewnej ilości powielania.

Kocham rspec z tego powodu:

MA 2 rzeczy do pomocy -

• Wspólne grupy przykładowe do testowania wspólnych zachowań.
  możesz zdefiniować zestaw testów, a następnie włączyć go do rzeczywistych testów.

• Zagnieżdżone konteksty.
  możesz zasadniczo mieć metodę "setup" i "teardown" dla określonego podzbioru testów, a nie tylko każdego z nich w klasie.

Im szybciej. Net / Java / inne frameworki testowe przyjmą te metody, tym lepiej (albo możesz użyć IronRuby lub JRuby do napisania testów, co osobiście uważam za lepszą opcję)

Wydaje mi się, że nie ma związku między bardziej duplikowanym i czytelnym kodem. Myślę, że Twój kod testowy powinien być tak dobry jak twój inny kod. Kod nie powtarzający się jest bardziej czytelny niż duplikowany, gdy jest dobrze wykonany.

Idealnie, testy jednostkowe nie powinny się zbytnio zmieniać po ich napisaniu, więc skłaniałbym się ku czytelności.

Aby testy jednostkowe były tak dyskretne, jak to możliwe, pomaga również skupić się na konkretnych funkcjach, które są kierowane.

Mając to na uwadze, staram się ponownie używać pewnych fragmentów kodu, których używam w kółko, takich jak kod konfiguracyjny, który jest dokładnie taki sam w zestawie testów.

"przeformułowano je, aby były bardziej suche-intencja każdego testu nie była już jasna"

Dlatego testy są podklasą UnitTest -- dzięki czemu można zaprojektować dobre zestawy testów, które są poprawne, łatwe do zweryfikowania i przejrzyste.

W dawnych czasach my miał narzędzia testowe, które używały różnych języków programowania. Trudno było (lub niemożliwe) zaprojektować przyjemne, łatwe w obsłudze testy.

Masz pełną moc -- jakiegokolwiek języka używasz -- Python, Java, C# -- więc używaj tego języka dobrze. Możesz uzyskać dobrze wyglądający kod testowy, który jest jasny i nie jest zbyt zbędny. Nie ma kompromisu.

Uważam, że kod testowy wymaga podobnego poziomu inżynierii, który normalnie byłby stosowany do kodu produkcyjnego. Na pewno mogą być argumenty przemawiające za czytelnością i zgadzam się, że to ważne.

Z mojego doświadczenia wynika jednak, że dobrze przemyślane testy są łatwiejsze do odczytania i zrozumienia. Jeśli jest 5 testów, które każdy wygląda tak samo, z wyjątkiem jednej zmiennej, która się zmieniła i twierdzenia na końcu, może być bardzo trudno znaleźć to, co ten pojedynczy różni item is. Podobnie, jeśli jest uwzględniona tak, że widoczna jest tylko zmienna, która się zmienia i twierdzenie, to łatwo jest natychmiast zorientować się, co robi test.

Znalezienie odpowiedniego poziomu abstrakcji podczas testowania może być trudne i uważam, że warto to zrobić.