È molto, molto difficile testare le dipendenze esterne in modo ripetibile automatizzato. Almeno senza creare più framework per falsificare la dipendenza esterna di quanto tu abbia il codice sotto test. E spesso quel genere di cose è comunque molto fragile, portando a molti fallimenti di test falsi.
Non sono un rubyist in nessuna misura, il seguente consiglio sarà un agnostico piuttosto linguistico. Quello che vorrei fare qui è:
- Avvolge la dipendenza esterna nella mia interfaccia. Tutto il mio codice dovrebbe parlare a questa interfaccia. e non patch direttamente alla libreria. A seconda della complessità di ciò che erano i dati di ritorno, prenderei in considerazione la possibilità di creare anche i miei oggetti DTO.
- Prova il mio codice contro versioni derise o con stub di questa interfaccia per assicurarmi che il mio capo del mondo si comporti correttamente con gli input corretti.
- Infine, prova a trovare un modo per testare la mia interfaccia pass-through al servizio esterno. Ma alla fine della giornata questa classe tende ad essere così semplice da non meritare lo sforzo.
Ma provare a testare i servizi esterni in un senso convenzionale può essere esasperante e orribilmente non efficace.
PS: dovrei aggiungere Ho appena scritto un bot IRC nell'ultimo fine settimana. Ho usato in gran parte TDD in C #, e di certo non ho testato l'angolo di connessione IRC al di fuori dell'uso di nUnit come imbracatura per alzare il codice sperimentale di cui avevo bisogno per capire come funziona la libreria.