Czy TDD jest wykonalne we wspólnych projektach open source

Powiedzmy, że chciałem rozpocząć projekt open source, który mam nadzieję / oczekuję, że wiele osób prześle łaty i tak dalej. Czy opłaca się stosować ścisłe podejście TDD? Czy mogę / powinienem oczekiwać / zaufać współpracownikom, że będą pisać testy jakości za każdym razem, gdy przesyłają łatkę?

Jedną z rzeczy, o których myślałem, jest pisanie zestawów testów dla poszczególnych raportów błędów i żądań funkcji oraz wymaganie, aby wszystkie łatki / żądania ściągnięcia przeszły pomyślnie testy, ale w tym momencie wydaje się, że lepiej byłoby po prostu napisać właściwość / poprawkę błędu siebie.

O ile wiem, większość dużych projektów open source, które używają TDD (lub przynajmniej piszą testy) wydają się być napisane głównie przez osobę lub zespół, gdzie łatwo jest egzekwować praktyki takie jak TDD.

open-source tdd collaboration

— DormoTheNord
źródło

Udostępnianie badań pomaga wszystkim. Powiedz nam, co próbowałeś i dlaczego nie spełnia twoich potrzeb. To pokazuje, że poświęciłeś trochę czasu, aby spróbować sobie pomóc, oszczędza nam to powtarzania oczywistych odpowiedzi, a przede wszystkim pomaga uzyskać bardziej konkretną i odpowiednią odpowiedź. Zobacz także How to Ask

— gnat

@gnat Przeszukałem StackExchange i pojawiło się kilka pytań, w których ludzie pytają o przykłady projektów open source z testami jednostkowymi, co nie jest tym samym, co moje pytanie. Zgodnie z twoją prośbą dodałem trochę więcej informacji.

— DormoTheNord,

DormoTheNord Myślę, że @gnat oznaczało konkretne, cytowane przykłady.

— haneefmubarak

„lepiej byłoby po prostu napisać funkcję / poprawkę”. Z testami czy bez? Czy jesteś zwolennikiem TDD, czy tylko sprawdzasz, czy jest to opłacalne w tym kontekście?

— JeffO

Oczywiście możesz / powinieneś oczekiwać od współpracowników pisania testów jakości za każdym razem, gdy przesyłają łatkę. Jest to nie tylko korzystne - jest dziś niezwykle powszechne w dużych projektach open source (mogę podać przykłady, jeśli chcesz).

— Benjamin Gruenbaum,

Odpowiedzi:

Naprawdę nie można egzekwować podejścia TDD (najpierw testowego) w projekcie open source, w którym poprawki mogą być przesyłane przez ogół społeczeństwa.

Co może wymusić jest to, że wszystkie poprawki musi mieć zestaw testów dla poprawki zawarte w plastrze i że tych przypadków testowych, a także wszystkie dotychczasowe przypadki testowe, musi przejść. Możesz to egzekwować, przyznając uprawnienia do zatwierdzania tylko kilku zaufanym programistom, o których wiadomo, że stosują i zgadzają się z zasadami projektu, oraz publicznie stwierdzając, że zgłoszenia / żądania ściągnięcia zostaną uwzględnione tylko wtedy, gdy otrzymają pozytywny przypadek testowy (z wystarczający zasięg).

Nie gwarantuje to, że test zostanie napisany jako pierwszy , ale gwarantuje, że test zostanie napisany .

— Bart van Ingen Schenau
źródło

Z pewnością właściciel repozytorium może odmówić wprowadzenia zmian niezgodnych ze standardami jakości projektu? Być może jakość i ilość składek ucierpiałaby, gdyby autorzy tego nie lubili, ale to nie znaczy, że nie możesz tego egzekwować. Pewno?

— Tom W

@TomW: W jaki sposób sprawdziłbyś, czy moje zgłoszenie jest tworzone zgodnie z praktykami TDD, a nie, na przykład, z testami napisanymi po zakończeniu wdrożenia?

— Bart van Ingen Schenau,

Ach, rozumiem co masz na myśli. Przypuszczam, że pewna utrata rygorystyczności jest nieunikniona, ale nadal możesz sprawdzić, czy kod pochodzi z testów, czy testy są wystarczająco szczegółowe i obejmują wszystko, co powinny. Nie jestem zaznajomiony z git, ale czy dla danego żądania ściągnięcia można sprawdzić sekwencję zatwierdzeń dla tego zestawu zmian, aby sprawdzić, czy programista zastosował odpowiedni proces do jego wytworzenia?

— Tom W

Innymi słowy, nie możesz potwierdzić własnego procesu wewnętrznego, ale możesz upewnić się, że jego wynik spełnia określony standard. Wymaganie testów i upewnienie się, że projekt jest logiczny, leży w gestii właściciela.

— Adrian Schneider,

Możesz poprosić ludzi o przesłanie łat tylko do testów, zanim będą mogli pracować nad kodem; zapewniłoby to dodatkową możliwość przejrzenia planowanego projektu przed napisaniem samego kodu.

W praktyce może to zabić entuzjazm ludzi, którzy przyczynili się do projektu - lub może rozpalić ogień u tych, którzy zgadzają się z twoją metodologią.

Recenzenci musieliby jednak bardzo dobrze radzić sobie z szybkim odwracaniem recenzji projektów, aby nie opóźniać rozwoju.

— Alex Feinman
źródło