TDD è praticabile in progetti collaborativi open source

Diciamo che volevo iniziare un progetto open source che spero / mi aspetto di avere molte persone che inviano patch e quant'altro. È possibile adottare un approccio TDD rigoroso? Posso / dovrei aspettarmi / fidarmi che i collaboratori scrivano test di qualità ogni volta che inviano una patch?

Una cosa a cui ho pensato è scrivere suite di test per singoli report di bug e richieste di funzionalità e richiedere che tutte le patch / richieste pull superino i test, ma a quel punto sembra che sarebbe meglio solo scrivere la funzione / bugfix me stessa.

Per quanto ne so, la maggior parte dei principali progetti open source che utilizzano TDD (o almeno test di scrittura) sembrano essere per lo più scritti esclusivamente da un individuo o da un team, dove è facile applicare pratiche come TDD.

open-source tdd collaboration

— DormoTheNord
fonte

Condividere la tua ricerca aiuta tutti. Raccontaci cosa hai provato e perché non ha soddisfatto le tue esigenze. Ciò dimostra che hai impiegato del tempo per cercare di aiutarti, ci salva dal ribadire risposte ovvie e soprattutto ti aiuta a ottenere una risposta più specifica e pertinente. Vedi anche Come chiedere

— Gnat

@gnat Ho cercato StackExchange e ci sono state alcune domande in cui le persone fanno degli esempi di progetti open source con unit test, che non è la stessa della mia domanda. Come da sua richiesta, ho aggiunto alcune ulteriori informazioni.

— DormoTheNord

DormoTheNord Credo che @gnat significasse esempi specifici citati .

— Haneefmubarak,

"sarebbe meglio solo scrivere la funzione / bugfix da solo." Con o senza test? Sei un sostenitore di TDD o stai solo verificando se è praticabile in questo contesto?

— JeffO,

Ovviamente puoi / dovresti aspettarti che i collaboratori scrivano test di qualità ogni volta che inviano una patch. Non è solo vantaggioso, è estremamente comune nei grandi progetti open source oggi (posso dare esempi se vuoi).

— Benjamin Gruenbaum,

Risposte:

Non è davvero possibile applicare un approccio TDD (test prima) su un progetto open source in cui le patch possono essere inviate dal pubblico in generale.

Ciò che è possibile applicare è che tutte le patch devono avere una serie di casi di test per le correzioni incluse nella patch e che tali casi di test, così come tutti i casi di test esistenti, devono passare. È possibile far valere ciò solo concedendo i diritti di commit a pochi sviluppatori fidati che sono noti per utilizzare e concordare con le politiche del progetto e dichiarando pubblicamente che gli invii / le richieste pull saranno incorporati solo se arrivano con il superamento di casi di test (con copertura sufficiente).

Questo non garantisce che il test sia scritto per primo , ma garantisce che il test sia scritto .

— Bart van Ingen Schenau
fonte

Sicuramente il proprietario del repository può rifiutare di apportare modifiche non conformi agli standard di qualità del progetto? Forse la qualità e la quantità dei contributi ne risentirebbero se i collaboratori non apprezzassero questo, ma questo non vuol dire che non si può far valere. Certamente?

— Tom W,

@TomW: Come verifichi che la mia presentazione sia creata secondo le pratiche TDD e non, ad esempio, con i test scritti dopo che l'implementazione è stata eseguita?

— Bart van Ingen Schenau,

Ah, capisco cosa intendi. Suppongo che una perdita di rigore sia inevitabile, ma è ancora possibile verificare che il codice venga fornito con i test, che i test siano sufficientemente granulari e coprano tutto ciò che dovrebbero. Non ho familiarità con Git, ma per una determinata richiesta pull, è possibile controllare la sequenza di commit per quel changeset per vedere che lo sviluppatore ha seguito un processo adeguato per produrlo?

— Tom W,

In altre parole, non è possibile confermare il proprio processo interno, ma è possibile garantire che l'output soddisfi un determinato standard. Richiedere test e assicurarsi che il design sia logico è di competenza del proprietario.

— Adrian Schneider,

Potresti chiedere alle persone di inviare patch di solo test prima che possano lavorare sul codice; ciò fornirebbe un'ulteriore opportunità per rivedere il progetto pianificato prima che il codice stesso sia scritto.

In pratica, questo potrebbe uccidere qualsiasi entusiasmo delle persone per il contributo al progetto - o potrebbe accendere un fuoco in coloro che sono d'accordo con la tua metodologia.

Tuttavia, i revisori dovrebbero essere molto bravi a invertire rapidamente le revisioni del progetto, in modo da non interrompere lo sviluppo.

— Alex Feinman
fonte