In primo luogo un po 'di background: stiamo riprogettando la nostra suite di prodotti che è stata scritta 10 anni fa e ha raggiunto il suo scopo. Una cosa che non possiamo cambiare è lo schema del database dato che abbiamo più di 500 client basati su questo sistema. Il nostro schema db ha oltre 150 tabelle. Abbiamo deciso di utilizzare Entity Framework 4.1 come DAL e di valutare ancora vari framework per l'archiviazione della nostra logica di business.
Sono un'indagine per portare i test unitari nel mix, ma ho anche confuso su quanto ho bisogno di impostare un ambiente TDD completo. Un aspetto della creazione di test unitari consiste nell'implementare il Repository, l'unità di lavoro e le strutture di simulazione ecc. Ciò significa che ci saranno costi e investimenti per la crescita del codice associata a tutti questi framework. Capisco che alcuni di questi potrebbero essere generati automaticamente, ma quando si tratta di cose come i comportamenti, sarà scritto per lo più a mano. Per essere chiari, non sto mettendo in dubbio l'importante unità di test del codice. Non sono sicuro che abbiamo bisogno di tutti i suoi componenti (come repository, mocking, ecc.) Quando siamo abbastanza sicuri del meccanismo di archiviazione / framework (SQL Server / Entity Framework). Tutto ciò che il codice gonfia con i repository generici ha senso quando hai bisogno di un layer generico con la possibilità di cambiarlo quando vuoi, ma è molto probabilmente uno YAGNI nel nostro caso. Ciò di cui abbiamo bisogno è più un test di integrazione in cui possiamo testare il nostro codice unitario con oggetti di deposito concreti e dati di test nel database. In questo scenario, l'esecuzione del test di integrazione sembra essere più utile nel nostro caso. Qualche idea se mi manca qualcosa qui?