Come posso prendere in giro la presenza di un file di proprietà sul classpath?

Question

Questo è sicuramente un problema comune. Ho un file di proprietà come my-settings.properties che viene letto da una classe di applicazione. Quando scrivo una classe di test, è necessario testare diversi scenari di cose che potrebbero essere presenti in my-settings.properties per garantire la massima copertura del codice (ad esempio file di proprietà vuoto, file di proprietà di base ecc.). Ma posso avere solo uno my-settings.properties nel mio src/test/resources.

Quale sarebbe davvero grande è se ci fosse solo alcune annotazioni

@MockFileOnClassPath(use = "my-settings-basic.properties", insteadOf = "my-settings.properties")

Poi ho potuto solo avere più file my-settings-XXX.properties nel mio /src/test/resources ed appena annotato quella corretta per ogni metodo di prova. Ma non riesco a trovare nulla di simile. Sto usando JUnit 4.12.

mi viene in mente un paio di soluzioni greggio:

1. Prima di ogni prova, trovare il file sul file system, copiare utilizzando filesystem di I/O, quindi eliminarlo di nuovo dopo il test. Ma questo è maldestro e comporta molta ridondanza. Per non parlare del fatto che non sono nemmeno sicuro se la directory classpath sarà scrivibile.
2. Utilizzare una struttura di simulazione per simulare getResource. Non ho idea di come avrei nemmeno farlo, soprattutto perché ci sono un milione di modi diversi per ottenere il file (, MyClass.class.getResourceAsStream(...), ClassLoader.getSystemClassLoader().getResourceAsStream(...) ecc)

Penso solo che questo deve essere un problema comune e forse c'è già una soluzione in JUnit, Mockito, PowerMock, EasyMock o qualcosa del genere?

MODIFICA: qualcuno ha specificato che questa domanda è un duplicato di Specifying a custom log4j.properties file for all of JUnit tests run from Eclipse ma non lo è. Questa domanda riguarda il voler avere un file di proprietà diverso tra le chiamate principali e quelle di test. Per me voglio avere un file di proprietà diverso tra una chiamata di test e un'altra chiamata di test.

Answer 1

Trovo che ogni volta che si tratta di file, è meglio introdurre il concetto di Resource.

esempio:

public interface Resource { 
    String getName(); 
    InputStream getStream(); 
} 

Poi si può passare la risorsa in via iniezione di dipendenza:

public class MyService { 
    private final Properties properties; 

    public class MyService(Resource propFile) { 
     this.properties = new Properties(); 
     this.properties.load(propFile.getStream()); 
    } 

    ... 
} 

Poi, nel codice di produzione è possibile utilizzare un ClasspathResource o forse un FileResource o URLResource ecc, ma nei tuoi test potresti avere un StringResource ecc.

Nota, se usi la primavera hai già un impl enfatizzazione di questo concetto. Maggiori dettagli here

Answer 2

È possibile modificare la classe Service per accettare il nome del file resource, quindi quindi utilizzare tale name per caricare il resource.

public class MyService { 

public MyService(String resourceFileName){ 
    //and load it into Properties getResourceAsStream(resourceFileName); 
} 
}