Cross-language Test-Driven Development

Is there a technique for unit testing both components in one run?

Questo sarebbe in realtà l'opposto del test dell'unità : test dell'unità, in particolare in stile TDD, significa testare i componenti in isolamento . Quindi la risposta è sì, "esegui suite di test separate per le sezioni JS e PHP ", altrimenti non si tratta di test di unità e non di TDD.

Naturalmente, i test di integrazione automatici possono testare "entrambi i componenti in una sola esecuzione" e puoi utilizzare esattamente gli strumenti che hai già menzionato (come il Selenium). Ma quelli sono in genere test più complessi, sviluppati al di fuori dei cicli TDD.

L'importante è distinguere tra TDD e ATDD . L'AT sta per "test di accettazione " e si riferisce allo sviluppo in cui si inizia per la prima volta con un test di accettazione, che probabilmente testerà l'intero stack. Questo è talvolta chiamato anche "sviluppo guidato da test esterno". Quando la gente parla di TDD, la "T" probabilmente si riferisce specificamente ai test unit .

Una parte fondamentale dei test unitari sta isolando l'unità in prova dalle sue dipendenze. Questo ti dà due vantaggi molto importanti:

• Puoi rendere i tuoi test estremamente veloci, quindi puoi eseguirli molto spesso come parte di un ciclo di feedback molto breve. Piuttosto che eseguirli, ad esempio, ogni ora, dovresti essere in grado di eseguire tutti i tuoi test unitari dopo ogni piccola modifica, in modo da ottenere immediatamente il loro feedback sul fatto che tale modifica abbia rotto qualcosa.

• I tuoi test possono essere indirizzati a un comportamento molto specifico. Se uno di questi fallisce, dovresti essere in grado di determinare quasi istantaneamente la natura esatta del bug che il test sta indicando.

Data l'importanza di questo isolamento, vorrai automaticamente che i test vengano ristretti a unità molto più piccole di quelle in cui i limiti della tua lingua ti costringono. Sebbene non sia una regola dura e veloce, ti aspetteresti spesso che una singola classe fosse un'unità testabile. Quindi in termini di TDD, il problema della lingua è più o meno irrilevante.

Se, invece, vuoi fare ATDD, assicurati di cercare le risorse in modo specifico (spesso è fatto come parte di BDD, quindi guarda anche gli strumenti mirati). Ecco dove qualcosa di simile al Selenium si inseriva naturalmente. Di solito, quando si fa ATDD si scrivono ancora test unitari e, in effetti, per superare ogni test di accettazione si può provare a guidare la sua implementazione anche con i test unitari. Quindi, anche se vuoi fare ATDD, capire come scrivere test di unità è ancora importante.

Inoltre non devi usare TDD per lo stack completo dell'applicazione. TDD come metodologia di sviluppo è più adatto per le parti logiche di un'applicazione. Le parti che richiedono un tocco più sperimentale, come detto il design del frontend, le interazioni certe o il dominio del database, sono fatte meglio in uno stile tradizionale, come non si sa ancora se questa sarà la versione finale.

Ma la logica dell'applicazione non dovrebbe cambiare in futuro, e se lo fai stai affrontando il tanto temuto insidioso insinuarsi. Ciò lo rende perfetto per una serie di test di regressione per dare fiducia ogni volta che si apporta una modifica al codice, che è l'obiettivo finale di TDD.

Lo zio Bob lo spiega meglio di me. link