Ci sono casi in cui non si dovrebbe usare lo sviluppo basato su test? [duplicare]

Fattori che limitano l'adozione industriale dello sviluppo basato su test , un documento di ricerca del 2011, ha esaminato 9.462 articoli su TDD e ha incluso 48 studi come base per la loro ricerca. Il documento tratta l'argomento del perché TDD non può essere usato in profondità, ma per facilità di consultazione, ecco un riassunto:

• Development time: Development time could be considered a business-critical factor for adopting new practices within an organization. Depending on the maturity of the organization, an up-front loss (in this case, increased development time) might overshadow a long-term gain (e.g., decreased overall project time, or increased product quality – both of which were reported in many of our included studies). Hence, internal organizational pressure might risk the proper usage of TDD.
• Experience/knowledge: When observing collected data from the included primary studies, we noticed that participants in the experiments (either students or professionals) were mostly provided with some training or tutorial on how to perform TDD. In several cases, the knowledge improved as participants would progress with the experiment. We expect that lack of knowledge or experience with TDD could create problems in its adoption.
• Design: There is no massive empirical support that the lack of design should be considered as a limiting factor for industrial adoption of TDD. However, there are a handful of studies reporting problems regarding lack of design in TDD, particularly in the development of larger, more complex systems. Moreover, the lack of upfront design has been one of the main criticisms of TDD since its introduction and even if the evidence supporting this criticism is sparse, so is the evidence contradicting it.
• Skill in testing: Since TDD is a design technique where the developer undertakes development by first creating testcases and then writes code that makes the test cases pass, it relies on the ability of the developer to produce sufficiently good test cases. Additionally, one study reports on the risk it brings to adopt TDD without having adequate testing skills and knowledge. We find it interesting that there are no explicit investigations of the quality of test cases produced by developers in TDD.
• TDD adherence: The combined view of five industrial case studies state that the inclusion of the lack of TDD adherence as a limiting factor. Basically, the studies state that (1) it is important to adhere to the TDD protocol, and (2) developers do stray from the protocol in several situations. It is however far from certain that there is a clean-cut cause-effect relationship between low TDD adherence and low quality. Not unlikely, confounding factors (e.g., tight development deadlines) might lead to both low TDD adherence and poor quality
• Domain and tool specific issues: Proper tool support for test automation is vital for the successful adoption of TDD. With the wide variety of studies reporting domain- and tool-specific issues as a limiting factor in the adoption of TDD, the factor would be difficult to ignore.
• Legacy code: TDD, in its original form, does not discuss how to handle legacy code. Instead, the method seems to assume that all code is developed from scratch, using TDD as the development method. As this is seldom the case in large development organization, adoption of TDD might be problematic. A lack of automated regression suites for legacy code hampers the flexibility provided by the quick feedback on changes provided by the regression suites, and may leave developers more anxious about how new changes may unexpectedly affect existing code.

Penso che tutto dipenda da una semplice domanda: Deve funzionare? Se lo fa, allora direi che è meglio fare TDD, nella maggior parte dei casi.

Per me, le eccezioni sono pezzi di codice molto leggeri. Sopporta l'impegno di testare manualmente ogni singolo ramo procedurale nel codice. Se questo sforzo è inferiore a quello di scrivere test automatici, direi che non sarebbe un problema non fare TDD. A proposito, se devi eseguire i test manuali più di una volta, lo sforzo viene moltiplicato.

Quindi, se ci pensiamo, non c'è quasi nessun tipo di software utile a cui lo sforzo di testare manualmente (più volte) sarebbe inferiore alla scrittura di test automatici. Posso solo pensare a piccoli proof-of-concept e codice dimostrativo, ma anche in questo caso preferirei praticare TDD, perché tale codice prototipo potrebbe diventare un software pienamente funzionante.

Ora, per quanto riguarda il TDD come pratica ufficiale nelle grandi aziende, posso solo rispondere in base alla società per cui lavoro, e no, non è . Ci sono aziende che richiedono unit test per essere scritte entro la fine di un'iterazione, con un intervallo "accettabile" di copertura del codice, ma questo è completamente diverso dalla pratica del TDD.

In ogni caso, noi, in qualità di sviluppatori di software, professionisti , dobbiamo decidere se praticare o meno TDD, non i nostri appaltatori.

Alcuni casi a cui riesco a pensare quando uno potrebbe non voler TDD sono:

• modifiche minori ai vecchi sistemi che non hanno test.
• modifiche minori ai vecchi sistemi privi di framework di test.
• progettazione e sviluppo di elementi visivi ed effetti.
• scadenze ravvicinate e una riluttanza a produrre un lavoro di qualità.

Il TDD non dovrebbe essere usato quando un approccio alternativo è più appropriato. La cosa fondamentale da ricordare è che gli approcci alternativi non sono tanto test manuali, quanto cose come:

• Scrivi e rivedi un documento di progettazione dettagliato
• Produci un design completo in uno strumento CASE , premi il pulsante "genera codice".
• Crea una serie di componenti riutilizzabili testati dall'unità, assemblare una soluzione da loro
• Esprimi il problema in termini di matematica, crea una soluzione provatamente corretta
• Definisci un linguaggio personalizzato in cui sia facile esprimere la soluzione
• Scrivi il codice che fa ballare la scimmia, premi Aggiorna.

La verifica automatizzata è particolarmente difficile per qualche motivo è un fattore che potrebbe guidare la scelta del metodo di progettazione. Ma è lontano dal fattore chiave; in effetti, molti altri approcci finiranno per eseguire test automatici o di più rispetto a TDD.

Una cosa che ho imparato a gestire con il codice legacy che ho fatto per progetti di medie e grandi dimensioni con > 1 milione di righe di codice, ha senso usare anche TDD. Ma è molto più difficile ottenere il tuo codice lì nei test.

Normalmente le basi di codice legacy non hanno alcun test in atto, quindi correggere un bug e scrivere un test unitario è un buon punto di partenza per ottenerne un po '. Ma normalmente devi refactoring il codice un po 'prima di poter scrivere questi test. C'è un buon libro in cui puoi imparare molto su TDD con il codice legacy (dipendenze che si infrangono, come scrivere il primo test e così via): link