Ho una classe che trarrebbe grande beneficio dai test di unità, ma pochi metodi che chiamano web server remoto devono essere sostituiti da qualcosa che fornisce risultati simulati. Le soluzioni probabili che vedo sono:
- Verifica la classe derivata che sovrascrive i metodi problematici (nessun codice relativo al test in produzione, solo i metodi devono essere non privati e non finali).
- Estrai metodi problematici in componenti separati.
Il secondo caso richiede di aggiungere questo componente in qualche modo durante i test e le esecuzioni di produzione, e potrebbe avere almeno le seguenti soluzioni:
- Hanno un campo protetto che può essere assegnato direttamente durante l'impostazione del test, sostituendo il componente lì. Rompe un po 'i concetti OOP.
- Chiedere al setter di impostare il componente. Non è ancora la migliore API in quanto questo componente non può essere sostituito improvvisamente dopo che l'oggetto principale diventa attivo con le sue funzioni. Sarebbe un metodo con la finestra temporale limitata per chiamare.
- Avere il costruttore che accetta un'implementazione interattiva o una simulazione. Questo rende la API un po 'strana (costruisci sempre e passa lo stesso oggetto).
- Avere il secondo costruttore per il test che accetta solo una simulazione, chiamate del costruttore di produzione
this(..) con l'istanza di produzione precostruita. - Avere qualcosa come il servizio di denominazione che risolve il componente (sembra un sacco di lavoro da creare e mantenere, se solo per il supporto di test, modello singleton).
- Usa framework di dipendenze per l'iniezione (se il progetto è più piccolo, sembra anche un sacco di spese generali).
Quali di queste soluzioni proposte sono "teoricamente corrette"? O forse alcune altre soluzioni sono più corrette?