2014-11-11 11 views
5

Sto cercando di trovare una risposta definitiva all'utilizzo dei rilevatori di Hamcrest nel codice non di prova. Ho fatto un po 'di ricerca, e hanno alcune citazioni contrastanti:È accettabile l'uso di dispositivi di verifica Hamcrest nel codice non di prova

  • Hamcrest su Wikipedia:

    Hamcrest è un framework che assist scrittura test del software nel linguaggio di programmazione Java. [snip] Questi matcher hanno usi in framework di test unitari come JUnit 2 e jMock.

  • Hamcrest su Github:

    Hamcrest è una libreria di matchers, che possono essere combinati per creare flessibili espressioni di intenti nei test.

  • Hamcrest su Google Code:

    Nota: Hamcrest non è una libreria di test: succede solo che matchers sono molto utili per i test.

Personalmente, io associo Matchers con i test, così ho tendono ad evitare l'uso di loro al di fuori dei test. Detto questo, non vedo limiti che possano impedire che vengano utilizzati al di fuori dell'ambito di un test.

Questo quindi si riduce a una preferenza personale?

+4

Basta usarlo. Non vedo perché utilizzarlo non sarebbe accettabile. – morgano

risposta

5

Ho usato Hamcrest in codice non testato diverse volte fino ad ora. Principalmente lo uso quando voglio testare condizioni diverse sullo stesso oggetto per ottenere un report di quali condizioni sono fallite per quali ragioni. Le singole condizioni vengono quindi rappresentate come oggetti diversi che hanno anche altri buoni effetti. Ad esempio, l'ispezione della configurazione dell'applicazione può produrre risultati i cui dati sono supportati per quali operazioni.

motivi per cui ho particolarmente uso hamcrest per questo tipo di operazione:

  • è stato progettato per fare questo (condizioni di prova non è solo fatto in codice di test)
  • non porta ulteriori dipendenze insieme
  • ampiamente conosciuta come molti utilizzano già per il codice di prova
  • ha un facile da usare e piccolo API
  • è facilmente estensibile e supporta composizione molto bene

Finalmente si riduce a scegliere lo strumento giusto per il lavoro. Ad esempio, la convalida del bean può essere utilizzata per svolgere lavori relativamente simili.È necessario prendere una decisione ponderata, che incorpori anche i requisiti del processo di sviluppo e dell'ambiente.

Anche l'utilizzo di dispositivi di corrispondenza è un buon metodo per utilizzare il principio Tell, non chiedere. È possibile passare un matcher al metodo per indicare quale valore di ritorno si prevede di restituire. Se l'oggetto in questione non corrisponde a quel matcher, può essere immediatamente lanciata un'eccezione con una buona descrizione dell'errore.

Inoltre, quando si confronta l'utilizzo di dispositivi di corrispondenza con lo Predicate di java 8, i dispositivi di corrispondenza hanno il vantaggio di essere in grado di fornire una descrizione, ma il lato negativo non è un'interfaccia funzionale.

Problemi correlati