Sviluppo incentrato sui test in tutte le lingue

La breve domanda: come si segue lo sviluppo test-driven su un progetto che si estende su più lingue?

In particolare, sto scrivendo un'applicazione Web che utilizza JavaScript e PHP e voglio seguire i principi TDD, ma non sono sicuro di come integrarli. Eseguo suite di test separate per le sezioni JS e PHP e uso simulazioni nella suite JS per emulare le risposte del server? Esiste una tecnica per testare l'unità di entrambi i componenti in una volta sola?

Questa è la mia prima esperienza con Test-Driven Development, quindi qualsiasi consiglio che puoi condividere su come renderlo meno scoraggiante sarebbe fantastico. Il motivo per cui l'ho scelto è che non appena ho finito un prototipo, i requisiti sono cambiati, costringendomi a cambiare il mio design. Ho pensato che se dovessi ricominciare, mi piacerebbe scrivere codice più estensibile con test di regressione integrati dall'inizio.

Sto scrivendo i miei test PHP in SimpleTest e i miei test JavaScript in JsTestDriver. Sono abituato ai paradigmi orientati agli oggetti, quindi ho alcune classi in PHP e sto facendo qualcosa di simile in JavaScript usando l'eredità prototipale. Ho anche iniziato a leggere questo libro su TDD in Python e questo su TDD in JavaScript , ma da tutto ciò che ho visto, questi non descrivono il test completo di un'applicazione (al di fuori dell'uso di qualcosa come Selenium o un altro driver web per eseguire test di accettazione front-end. TDD non è semplicemente tagliato per gli sviluppatori full-stack?

Esiste una tecnica per testare l'unità di entrambi i componenti in una volta sola?

Questo sarebbe effettivamente l'opposto del test unitario: test unitari, specialmente nello stile TDD, significa testare i componenti in modo isolato . Quindi la risposta è sì, "eseguire suite di test separate per le sezioni JS e PHP ", altrimenti non si tratta di unit test e non di TDD.

Naturalmente, i test di integrazione automatizzata possono testare "entrambi i componenti in una volta" e puoi utilizzare esattamente gli strumenti che hai già menzionato (come il selenio). 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 collaudo ", e questo si riferisce allo sviluppo in cui si inizia per la prima volta con un test di collaudo, che probabilmente testerà l'intero stack. Questo è talvolta chiamato anche "sviluppo guidato dai test esterni". Quando le persone parlano di TDD, la "T" probabilmente si riferisce specificamente ai test unitari .

Una parte fondamentale dei test unitari è l'isolamento dell'unità sotto test 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. Invece di eseguirli, diciamo, ogni ora, dovresti essere in grado di eseguire tutti i test unitari dopo ogni piccola modifica, in modo da ottenere immediatamente il loro feedback sul fatto che quella modifica abbia rotto qualcosa.

• I tuoi test possono essere mirati contemporaneamente a comportamenti molto specifici. Se uno di questi fallisce, dovresti essere in grado di determinare quasi all'istante la natura esatta del bug indicato dal test.

A causa dell'importanza di questo isolamento, vorrai automaticamente che i test siano limitati a unità molto più piccole di quelle che i tuoi confini linguistici ti costringono a fare. Sebbene non sia una regola dura e veloce, ci si aspetterebbe spesso che una singola classe sia un'unità testabile. Quindi, in termini di TDD, il problema della lingua è più o meno irrilevante.

Se, d'altra parte, vuoi fare ATDD, assicurati di esaminare le risorse per questo in modo specifico (spesso è fatto come parte di BDD, quindi guarda anche gli strumenti mirati a questo). Ecco dove qualcosa di simile al Selenio si adatterebbe naturalmente. Di solito, quando si fa ATDD si scrivono ancora unit test, e infatti per superare ogni test di accettazione è possibile testare la sua implementazione anche con unit test. Quindi, anche se vuoi fare ATDD, capire come scrivere unit test è ancora importante.

Inoltre, non è necessario utilizzare TDD per l'intero stack 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 ad esempio il design del frontend, certe interazioni o il dominio del database, sono meglio realizzate in uno stile tradizionale in quanto non si sa ancora se sarà la versione finale.

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

Lo zio Bob spiega così meglio di me. https://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html