Come @Robert ha sottolineato nei commenti, dipende davvero dal sistema che stai cercando di costruire, non ci sono soluzioni adatte a tutti.
Come regola generale se si hanno diversi tipi di fetch (almeno due) che possono essere utilizzati nel codice di produzione, il secondo approccio probabilmente inizierà a dare un senso. Più tipi di fetch hai, più è giustificabile, secondo il mio stile di programmazione.
Invece, se ritieni di essere spinto verso la seconda soluzione solo perché hai bisogno di fornire una simulazione del test, ci penserei due volte. Ho sempre pensato che "scrivere codice coincidente e ragionevole" e "scrivere codice completamente verificabile" a volte nella mia esperienza due aspetti dovresti trovare un compromesso tra. Ad esempio, ricordo che una volta far parte di un progetto era la piena testabilità era il nostro obiettivo principale, seguendo il secondo approccio ci siamo ritrovati con molte classi con molte dipendenze. I nuovi arrivati nel progetto hanno cominciato a trovare difficile comprendere il vero significato di tutte quelle dipendenze. Devo ammettere che d'altra parte probabilmente avremmo potuto gestire le dipendenze in un modo migliore.
In ogni caso, se il tuo vero problema è di prendere in giro il fetcher, puoi dare un'occhiata a mock-require . Non l'ho mai usato, ma mi sembra che faccia quello che ti serve nel tuo esempio.