Se provo un involucro di servizio, dovrei astrarre tutto?

Question

Ho una lezione di Service Manager utilizzata per astrarre le mie chiamate dal mio progetto MVC al mio servizio di riposo. Tutta la classe Manager fa è impostata le chiamate di resto (utilizzando RestSharp) e restituire i dati di servizio all'applicazione MVC.

Quindi, all'inizio ho pensato di non testare una classe così banale, ma ho deciso che i test salvaguardano i cambiamenti futuri che potrebbero essere più complessi.

Tuttavia, ecco il mio dilemma. Fino a che punto dovrei astrarre le cose solo per poter testare in isolamento?

Quindi, sto facendo iniettare il mio RestClient da MVC nella mia classe manager. Lascio che l'iniettore MVC imposti l'URL di base. Tutto questo sto bene, ma ecco le domande che ho:

• Per la mia chiamata del metodo, dovrei avere il mio metodo di assumere un parametro (UserId) e un Irstrequest?
  • Il mio problema è che all'improvviso il mio generico servicemanager diventerà specifico per il riposo poiché la mia interfaccia dovrebbe includere entrambi i parametri.
• Se non inietto l'Irestrequest nel metodo e lascia che l'implementazione lo crei, è OK poiché questo verrà ignorato poiché il metodo principale da testare è RestClient.execute, che verrà scontrato e non si preoccuperà dell'attuale Restreequest?
  • In effetti, poiché questo fa parte dell'implementazione, potrei forse deridere e verificare che il metodo Execute venga inviato nell'oggetto Restriquest appropriato?
• Oppure, non dovrei iniettare l'Irestrequest, ma invece iniettare un Irequestresolver nel mio costruttore? Quindi, nella mia methodcall, posso semplicemente usare Irequestresolver, che prenderà una stringa che rappresenta il metodo. Questo verrà quindi utilizzato per capire i parametri di RestRequest e restituire un oggetto Restrequest compilato in modo appropriato per il metodo?
• Oppure, dovrei essenzialmente fare il sotto-bullt sotto il mio primo proiettile e usare l'implementazione concreta.
• Altre opzioni che mi mancano?

Mi sto appoggiando al quarto proiettile mentre arriva alla soluzione effettiva da testare?

Fammi sapere se hai bisogno di ulteriori dettagli per aiutarmi a risolvere il mio dilemma.

Answer 1

Dopo averne discusso con un amico, ho deciso di utilizzare l'implementazione concreta.

Il motivo è che questo oggetto è in realtà solo un POCO e non è necessario astrarre questo (anche se viene fornita un'astrazione). Questa è la mia concreta implementazione del mio chiamante di servizio, quindi la soluzione effettiva da testare è la chiamata. Probabilmente lo deriderò e verificherò che il restrequest venga chiamato come dovrebbe essere.

Ma la risposta breve che abbiamo inventato è che i Poco non hanno bisogno di essere astratti.

Answer 2

Conosco bene questo dilemma; e sono stato qui alcune volte.

Quando si tratta di esso, potresti astrarre tutto, ma finisci con test insignificanti e scopri che stai scrivendo un framework di test che non importa o stai effettivamente bypassando le norme del framework accettate alla ricerca di "uno" vera metodologia di test '. In realtà ho avuto conversazioni in cui le persone hanno discusso onestamente di passare interfacce astratte in cui avresti solo bisogno di mettere un numero intero.

Mentre scrivo questo ho visto la tua risposta; E sono completamente d'accordo.

Finché puoi convalidare i presupposti e il comportamento di prova, allora stai facendo abbastanza; Come dici tu - devi solo verificare che le cose siano cambiate e tu stesso conosci i confini del tuo contesto - il fornitore cambierà realisticamente mai? No - non astrarre.

Di recente ho archiviato alcune soluzioni CRM Microsoft Dynamics su larga scala per il mio datore di lavoro; Alla fine i miei test presumono che l'API CRM sia OK e testino solo il comportamento dei miei involucri.

Ad ogni modo, questo è solo il campo da baseball come lo vedo, spero che questo abbia un certo valore per te!