Test dell'unità di scrittura solo per le applicazioni che li richiedono [chiuso]

No, ho il sospetto che il problema qui sia che il proprietario della società non capisce veramente che uno dei punti chiave di TDD è che devi farlo dall'inizio di un progetto altrimenti probabilmente non succederà mai, almeno questa è stata la mia esperienza in cui ogni volta che viene provato ad essere adottato a metà progetto cade a pezzi abbastanza rapidamente. Come metodo, posso apprezzare TDD e, se un posto lo usasse, probabilmente mi ambienterei. Tuttavia, non sono sicuro che molti posti possano vedere il pieno valore di fare le cose in quel modo e quindi è come cercare di educare il proprietario che non è all'altezza, dato che non capisco proprio che sarebbe la mia interpretazione qui.

Non c'è niente di sbagliato nel preferire uno stile e cercare aziende che usano una metodologia specifica, purché capisca come limitare il pool di potenziali datori di lavoro in questo caso.

Non è troppo difficile immaginare progetti che non traggano alcun beneficio dallo sviluppo basato su test.

Dopotutto, se il codice non verrà mai aggiornato, è così semplice che quasi non può essere scritto in modo errato e ha così pochi casi di variazione che non possono accadere, quindi scrivere i test non aiuta affatto.

Naturalmente, ciò che è difficile immaginare è un negozio di sviluppo software professionale che fa questo genere di cose giorno dopo giorno, e riesce a rimanere in attività.

Non dovrebbe essere la dimensione di un progetto che determina la scelta di TDD o meno. Dovrebbe essere la complessità del codice e la possibilità di riutilizzo.

Una percezione comune di TDD (o qualsiasi pratica che includa la scrittura di un vasto numero di codici di test automatizzati insieme al codice "reale") è che si aggiunge al costo di un progetto: il tempo di scrivere il codice di test unitario e il tempo necessario per mantenere il codice di test unitario. Dopo tutto, c'è più codice, giusto? non puoi venire gratis, vero? Come tale, TDD è pensato come un sovraccarico. Certo, fornisce un certo valore, ma è costoso.

Per la gestione, i costi devono essere giustificati. Non tutti i widget richiedono i più alti standard di costruzione possibili, e allo stesso modo non tutti i progetti dovrebbero aver bisogno di TDD, giusto? Ad un certo punto, un progetto potrebbe diventare abbastanza sensibile da giustificare il TDD e, a quel punto, ne vale la pena.

Come sviluppatore che si trova a proprio agio con TDD, si vede che il TDD fatto bene non aggiunge necessariamente al costo del progetto, ma può effettivamente ridurne i costi, specialmente a lungo termine. Ne sei convinto, ma è una dura vendita ad altri sviluppatori che si trovano a proprio agio con il loro stesso processo. È una vendita ancora più difficile da gestire.

La soluzione migliore è mostrare (altri sviluppatori, gestione) che i vantaggi di TDD superino i costi. Ci vuole tempo. Potrebbe non succedere mai. Ma non arriverà da nessuna parte nel tentativo di "spingere TDD come politica aziendale" senza prima dimostrare il suo valore.

company owner: "all the devs here know how to do TDD, they'll do it when required".

È abbastanza ovvio che il proprietario dell'azienda sta esaurendo gli argomenti e cerca di concludere la discussione.

Ma onestamente, purché il proprietario della società non sia anche lo sviluppatore principale, stai parlando con la persona sbagliata. Il TDD è qualcosa che devi convincere i tuoi colleghi dev e, se loro sono disposti ad adottarlo, il proprietario dell'azienda probabilmente non resisterà. Se il tuo capo è bravo, ascolterà quello che dice tutto il team, e tu hai solo una voce tra tante. Accettalo se vuoi essere un buon lavoratore di squadra.