classe d'affaires de conception pour test unitaire

Question

J'essaie de nettoyer mon code pour le rendre testable à l'unité. Je sais que des tests unitaires doivent être créés lors du codage mais ... Je dois le faire maintenant, avec le code complété.

Ma classe d'affaires est plein de méthodes avec une implémentation similaire comme:

var rep=new NHrepository<ModelClass1>(Session); 
rep.Where(x=>x.Field1==1).ToList(); 

première erreur (de mon point de vue) est que je ne dois pas utiliser « nouveau », mais plutôt utiliser DI et ajouter dans les paramètres de ctor un INHrepository modelClass1Repository.

Si dans ma classe j'ai plusieurs référentiels de classes de modèles différents? Chacun doit être dans le ctor? Ou probablement business class n'est pas construit avec le principe SeparationOfConcern?

Answer 1

Vous avez raison à propos de l'injection de dépendance.

En outre, je vous recommande fortement de lire Working Effectively with Legacy Code si vous envisagez d'écrire des tests unitaires pour votre code existant.

Answer 2

Une approche largement utilisée est d'avoir des référentiels n en tant que paramètres à vos constructeurs comme vous soupçonnaient déjà

Une autre approche couramment utilisée consiste à utiliser un cadre d'injection de dépendance tels que Ninject. Cela vous permet d'écrire des choses comme:

[Inject] 
public IAbstractRepository<Company> companiesRepository { get; private set; } 

[Inject] 
public IAbstractRepository<User> usersRepository { get; private set; } 

Vous pouvez alors Ninject injecter la mise en œuvre appropriée de l'interface en fonction du scénario d'utilisation (par exemple, un dépôt de faux pour les tests ou un véritable référentiel pour la production)

Answer 3

Votre classe affaires devrait avoir un constructeur avec 2 paramètres, un pour chaque référentiel. Votre entreprise devrait exposer 2 interfaces, et votre persistance devrait fournir leurs implémentations.