Se fatto bene, la tua seconda strategia può avere il meglio di entrambi i mondi:
Write part of the tests in isolation
Isolare la maggior parte dei test da servizi esterni è una buona idea perché non hai alcun controllo su quel servizio. Lo scenario peggiore è quello di far fallire in modo intermittente i test unitari, perché alla fine inizierai a ignorare i guasti, a quel punto i test sono inutili. La creazione di una simulazione che fornisce risposte coerenti ai test rende molto più semplice verificare come reagisce il codice a una determinata risposta dal servizio esterno.
create single bigger functional test for every feature that tests it using externals
Ciò può fornire informazioni importanti sul comportamento del sistema più vicino alle effettive condizioni operative, consentendo di riconoscere e gestire problemi diversi da quelli che si incontrano quando vengono derisi i servizi esterni, come problemi di rete o input o output di formattazione dei dati errori.
sometimes you don't know how external source might react in some conditions, it's hard to mock it (for example Solr with complex query)
sometimes you can forget about software-specific case (for example switching from MySQL to Postgres, while using ORM, might return different results and cause some other problems)
Se puoi riprodurre attendibilmente alcune risposte dal servizio esterno e vuoi verificare che il tuo codice reagisca ad esso in un certo modo, allora ha senso testarlo. L'importante è che non permetta guasti intermittenti nei test che, ad es. corri con ogni build. Ho visto degli ottimi sviluppatori disattivare i test perché era necessario creare una build e non avevano il tempo di correggere un test complesso e oscuro. È una brutta situazione, perché i test non servono più al loro scopo e la fiducia in essi è ridotta.