Come posso scrivere questi servizi usando SOLID e tenerli facili da testare?

0

Sto cercando di scrivere un paio di classi usando i principi SOLID e avendo qualche problema.

Il problema è abbastanza semplice. Ho un'applicazione che tiene traccia dei lead. I lead vengono creati quando gli eventi vengono sollevati dal cliente, ad es. Download di file, registrazione, visualizzazione di pagina, ecc. Un lead può avere più opportunità, ad esempio opportunità per prodotti diversi.

  1. Un lead dovrebbe essere creato se non esiste.
  2. Un'opportunità dovrebbe essere creata per quel lead, se non esiste
  3. Il punteggio principale dovrebbe essere incrementato in base a una tabella di punteggio di eventi

Il modo in cui volevo farlo era avere una classe LeadEventHandler che chiami tre servizi TrackLead, TrackOpportunity e IncrementLeadScore. Sembra ok, ma testare LeadEventHandler mi ha richiesto di usare any-instance che è un odore di codice.

Nota So che potrei testare l'intera catena in LeadEventHandler, ma per motivi di apprendimento volevo testare da solo. Avrei potuto iniettare le dipendenze in LeadEventHandler, ma questo non sembrava corretto.

Sarebbe bello se permettessi ai test di guidare il mio codice, ma mi sembra di imbattersi in parecchi ostacoli.

    
posta Ryan-Neal Mes 03.11.2014 - 09:30
fonte

1 risposta

1

Parlando in modo univoco delle tue lezioni:

TrackLead, TrackOpportunity 

Sono già a grana fine e pertanto dovrebbero essere conformi alla singola responsabilità di S.

La tua classe:

LeadEventHandler 

Il tuo gestore di eventi di lead è come un controller per tutti questi processi più piccoli, quindi per fare affidamento sulle classi TrackLead e Trackopportunity lo rende compatibile con DI ma non necessariamente 'O' in quanto non è facilmente apribile all'estensione. Per semplificare questo accertarsi che gli eventi Lead siano memorizzati all'interno di un elenco in LeadEventHandler che verrà enumerato ogni volta che viene ricevuto un evento. In questo modo i processori di eventi possono essere aggiunti in fase di esecuzione o da una configurazione esterna. Rendendolo conforme a "O" senza modificare il codice di LeadEventHandler

Per quanto riguarda i test unitari, le istanze di TrackLead e TrackOpportunity dovrebbero essere mock / stub durante il test di LeadEventHandler perché non dovresti testarne la funzionalità ma solo che i loro metodi di entry point sono stati chiamati

PS: il sistema che stai descrivendo è molto adatto per il modello di bus basato su eventi / messaggi. Forse puoi implementare qualcosa di simile

    
risposta data 03.11.2014 - 11:53
fonte

Leggi altre domande sui tag