Co oznacza „DAMP not DRY”, kiedy mówimy o testach jednostkowych?

345

Słyszałem, jak ktoś powiedział, że testy jednostkowe (np. NUnit, jUnit, xUnit) powinny być

DAMP nie wysycha

(Np. Testy jednostkowe powinny zawierać „wilgotny kod”, a nie „suchy kod”)

O czym oni rozmawiają?

unit-testing

— Ian Ringrose
źródło

2

Nie ma nic specjalnego w testach jednostkowych, które gwarantują kodowanie bez DRY. Pisanie testów bez DRY jest pretekstem dla leniwych programistów do próby wykreślenia terytorium dla ich lenistwa. Mówiąc najprościej, SUSZENIE i czytelność są kwestiami ortogonalnymi.

— Acumenus,

2

SUSZENIE zwiększa odległość nawigacji kodu, co z kolei powoduje większe obciążenie psychiczne do zrozumienia. Dotyczy to „normalnego” środowiska tekstowego. Edytor projekcyjny może zmniejszyć ortogonalność kodu, ale nie w każdym przypadku.

— Peter

Polecam ten artykuł: enterprisecraftsmanship.com/posts/dry-damp-unit-tests

— Vladimir

596

To równowaga, a nie sprzeczność

DRY wilgotne i nie są ze sobą sprzeczne, a oni zrównoważyć dwa różne aspekty kodu w konserwacji . Utrzymywalny kod (kod, który można łatwo zmienić) jest tutaj ostatecznym celem.

DAMP (opisowe i znaczące zwroty) poprawia czytelność kodu.

Aby zachować kod, najpierw musisz go zrozumieć. Aby to zrozumieć, musisz to przeczytać. Zastanów się przez chwilę, ile czasu spędzasz na czytaniu kodu. To dużo. DAMP zwiększa łatwość konserwacji, skracając czas niezbędny do odczytania i zrozumienia kodu.

DRY (nie powtarzaj się) promuje ortogonalność kodu.

Usunięcie duplikacji gwarantuje, że każda koncepcja w systemie ma jedną wiarygodną reprezentację w kodzie. Zmiana koncepcji pojedynczej firmy powoduje pojedynczą zmianę w kodzie. DRY zwiększa łatwość konserwacji, izolując zmianę (ryzyko) tylko do tych części systemu, które muszą się zmienić.

Dlaczego więc powielanie jest bardziej dopuszczalne w testach?

Testy często zawierają nieodłączne powielanie, ponieważ ciągle testują to samo, tylko z nieco innymi wartościami wejściowymi lub kodem konfiguracji. Jednak, w przeciwieństwie do kodu produkcyjnego, to powielanie jest zwykle izolowane tylko do scenariuszy w ramach jednego urządzenia testowego / pliku. Z tego powodu powielanie jest minimalne i oczywiste, co oznacza, że stwarza mniejsze ryzyko dla projektu niż inne rodzaje powielania.

Ponadto usunięcie tego rodzaju powielania zmniejsza czytelność testów. Szczegóły, które były wcześniej duplikowane w każdym teście, są teraz ukryte w nowej metodzie lub klasie. Aby uzyskać pełny obraz testu, musisz teraz mentalnie ponownie złożyć wszystkie te części razem.

Dlatego też, ponieważ powielanie kodu testowego często niesie mniejsze ryzyko i sprzyja czytelności, łatwo jest zobaczyć, jak uważa się go za akceptowalny.

Z zasady faworyzuj DRY w kodzie produkcyjnym, faworyzuj DAMP w kodzie testowym. Chociaż oba są równie ważne, przy odrobinie mądrości możesz przechylić równowagę na swoją korzyść.

— Chris Edwards
źródło

18

To świetne, zwięzłe podsumowanie. Chciałbym również zauważyć, że test DAMP jest bardziej odporny na zmieniające się wymagania, a pomiar oczywistości testu jest ogromną korzyścią, gdy ktoś inny ma za zadanie przepisanie testów, aby spełnić nowe wymagania. Jesper Lundberg ma również dobrą rozprawę na ten temat.

— Jason

3

@Jason, Btw jest link do „Jesper Lundberg ma również dobrą rozprawę na ten temat” ?

— Pacerier,

2

@JohnSaunders, możesz uniknąć części tego powielania, korzystając z wzorca testowego konstruktora danych: natpryce.com/articles/000714.html

— si618

2

WYSYŁANIE kodu testowego może stworzyć nieznany test, wprowadzając tajemniczego gościa

— jayeff

1

Dodałbym również, że dobrze napisane testy są zasadniczo dokumentacją / komentarzami do twojej aplikacji. Bardziej opisowe pomaga wyjaśnić twoje zamiary innym programistom. I jak mówi OP, są one niezależne w każdym teście, więc zagrożenie dla twojej aplikacji jest minimalne. Najgorszym scenariuszem jest to, że masz zbędny test lub konfigurację testową i uruchomienie zestawu testowego trwa dłużej. Wolę się mylić ze względu na dobry zasięg testu.

— Lee McAlilly,

60

DAMP - Zwroty opisowe i znaczące.

„DAMP not DRY” ceni czytelność przy ponownym użyciu kodu. Idea DAMP zamiast DRY w przypadkach testowych polega na tym, że testy powinny być łatwe do zrozumienia, nawet jeśli oznacza to, że przypadki testowe mają czasem powtarzający się kod.

Zobacz także Czy zduplikowany kod jest bardziej tolerowany w testach jednostkowych?za dyskusję na temat zalet tego punktu widzenia.

Być może został wymyślony przez Jaya Fieldsa w odniesieniu do języków specyficznych dla domeny.

— Dominic Rodger
źródło

1

Dobra odpowiedź i link do powiązanego pytania. Nie ma idealnej opcji DAMP vs DRY. Chcemy, aby kod był jak najbardziej suchy, a podczas testowania oznacza to, że nie jest tak suchy, że test staje się trudny do zrozumienia. Gdy test się nie powiedzie, chcę, aby powód był oczywisty, aby programista mógł zacząć naprawianie SUT, co oznacza, że skłaniam się w kierunku kodu DAMP w testach. Jak większość koncepcji programistycznych, zawsze można posunąć się za daleko. Jeśli kod testu jednostkowego jest tak suchy, że określenie, jak i dlaczego test się nie powiódł, może być „zbyt suchy”.

— Gerald Davis,

29

„SUCHY” to „Nie powtarzaj się”

Jest to termin używany do informowania ludzi o pisaniu kodu, który jest wielokrotnego użytku, abyś nie pisał podobnego kodu w kółko.

„DAMP” to „opisowe i znaczące zwroty”.

Termin ten ma na celu poinformowanie Cię o napisaniu kodu, który będzie łatwo zrozumiały dla osoby, która na niego patrzy. Jeśli będziesz przestrzegać tej zasady, będziesz mieć długie i opisowe nazwy zmiennych i funkcji itp.

— Spudley
źródło

15

AIUI, DRY to nie tylko kwestia oszczędzania czasu dzięki możliwości ponownego użycia - zapobiega także „zsynchronizowaniu” różnych ścieżek kodu. Jeśli skopiujesz i wkleisz tę samą logikę w wielu klasach, każde wystąpienie tego kodu będzie musiało zostać zaktualizowane, gdy wymagana jest zmiana. (I nieuchronnie jeden z nich nie wybuchnie i wysadzi się w powietrze podczas ćwiczeń.)

— Andrzej Doyle

20

Wilgotne = „opisowe i znaczące zwroty” - testy jednostkowe powinny być w stanie „odczytać”:

Czytelność jest ważniejsza niż unikanie zbędnego kodu.

Z artykułu:

DAMP oznacza „opisowe i znaczące frazy” i jest przeciwieństwem DRY, nie w tym sensie, że mówi „wszystko powinno wyglądać jak śmietnik i być niemożliwe do odczytania”, ponieważ czytelność jest ważniejsza niż unikanie zbędnego kodu.

Co to znaczy i gdzie go używać?

DAMP ma zastosowanie głównie podczas pisania kodu testowego. Kod testowy powinien być bardzo łatwy do zrozumienia do tego stopnia, że dopuszczalna jest pewna nadmiarowość.

— Stuartd
źródło

11

DAMP oznacza „opisowe i znaczące frazy” i jest przeciwieństwem DRY, nie w tym sensie, że mówi „wszystko powinno wyglądać jak śmietnik i być niemożliwe do odczytania”, ponieważ czytelność jest ważniejsza niż unikanie zbędnego kodu.

http://codeshelter.wordpress.com/2011/04/07/dry-and-damp-principles-when-developing-and-unit-testing/

— Piotr
źródło

11

Jest tu już kilka odpowiedzi, ale chciałem dodać kolejną, ponieważ nie sądziłem, że koniecznie wyjaśniają to tak dobrze, jak potrafią.

Ideą DRY (nie powtarzaj się) jest to, że w kodzie aplikacji chcesz uniknąć zbędnego lub gadatliwego kodu. Jeśli masz coś, co twój kod musi zrobić wiele razy, powinieneś mieć do tego funkcję lub klasę, zamiast powtarzać podobny kod w kilku miejscach.

Jest to dość dobrze znana koncepcja programowania.

DAMP (opisowe i znaczące zwroty) służy do testów jednostkowych. Chodzi o to, że nazwy metod testów jednostkowych powinny być długie i opisowe - w efekcie krótkie zdania opisujące to, co testujesz.

na przykład: testWhenIAddOneAndOneIShouldGetTwo() { .... }

Kiedy czytasz nazwę metody DAMP taką jak ta, powinieneś dokładnie zrozumieć, co pisarz testowy próbował osiągnąć, nawet bez konieczności odczytywania kodu testowego (chociaż kod testowy może również podążać za tą koncepcją, oczywiście z niepotrzebnymi nazwami zmiennych, itp).

Jest to możliwe, ponieważ metoda testu jednostkowego ma bardzo specyficzne dane wejściowe i oczekiwane wyniki, więc zasada DAMP działa dla nich dobrze. Metody w głównym kodzie aplikacji raczej nie będą wystarczająco szczegółowe, aby uzasadnić takie nazwy, szczególnie jeśli napisałeś je z myślą o zasadzie DRY.

DAMP i DRY nie są ze sobą sprzeczne - obejmują różne aspekty pisania kodu - ale mimo to nie są zwykle używane razem, ponieważ metody napisane z myślą o zasadzie DRY byłyby ogólne i mało prawdopodobne, aby były odpowiednie na wysoce specyficzną nazwę metody. Dlatego, jak wyjaśniono powyżej, kod aplikacji powinien być SUCHY, a kod testu jednostkowego DAMP.

Mam nadzieję, że to trochę lepiej to wyjaśni.

— SDC
źródło

5

Zgadzam się z Chrisem Edwardsem, że musisz znaleźć równowagę między nimi. Inną rzeczą, na którą należy zwrócić uwagę, jest to, że jeśli próbując usunąć duplikację, w końcu dodajesz dużo dodatkowej struktury w kodzie testu jednostkowego (tj. Przy ekstremalnym podejściu DRY), ryzykujesz wprowadzeniem tam błędów. W takiej sytuacji musiałbyś albo przetestować jednostki testami jednostkowymi, albo pozostawić fragmenty struktury nietestowane.

— Philip Atz
źródło

0

Nie chcę tutaj powielać wysiłku, ale możesz mieć testy, które są DAMP, ale mają zaletę DRY. Z drugiej strony testy DRY w niektórych przypadkach nie spełniają testów DAMP.

Pisałem na blogu o DRY vs DAMP, który zawiera kilka przykładów.

Żadne z tych podejść nie powinno być twoim jedynym rozwiązaniem, czasami DAMP to przesada, innym razem bardzo miły dodatek.

Zasadniczo należy stosować zasadę trzech. Jeśli zauważysz duplikację po raz trzeci, warto przyjrzeć się pisaniu testów w stylu DAMP, ale nawet wtedy nie wszystkie duplikacje są złe . Kontekst ma znaczenie.

— Finglas
źródło