2010-06-20 5 views
2

J'utilise NHibernate pour l'accès aux données. Je travaille sur l'écriture de tests pour ma couche d'accès aux données et j'ai un scénario dans lequel je sélectionne des enregistrements dans une plage de dates spécifique. En test, je génère des données de test en sélectionnant simplement des dates aléatoires dans une plage, puis j'essaie de sélectionner des enregistrements avec des dates dans un sous-ensemble de cette plage. Par exemple, je génère des enregistrements avec des dates entre hier et demain, puis je sélectionne uniquement les enregistrements qui ont une date d'aujourd'hui.NHibernate Generated values ​​and Testing

Le problème est que ces dates sont généralement générées par la base de données - elles sont définies à generated="insert" essentiellement. Existe-t-il un moyen de configurer NHibernate de manière à ce qu'il utilise la date de création de la base de données lorsque celle-ci n'est pas fournie par l'utilisateur? Si ce n'est pas le cas, quelqu'un a-t-il une stratégie pour atténuer cela pendant les tests?

Répondre

0

Initialisez la propriété DateTime sur votre entité à DateTime.Now lors de sa construction. Donnez-lui un setter protégé et, dans votre code de test, implémentez un type dérivé qui expose une méthode pour le définir.

par exemple

public class RealEntity 
{ 
    public virtual int Id { get; private set;} 
    ... 
    public virtual DateTime Created { get; protected set; } 
} 

[TestFixture] 
public class SomeTest 
{ 
    ... 

    public class Testable : RealEntity 
    { 
     public void SetCreatedDate(DateTime date) 
     { 
      Created = date; 
     } 
    } 
} 
+0

Je trouve l'exposition des choses privées/protégées douteuse. La manière dont vous proposez de coupler le test avec la structure interne de la classe testée. Fondamentalement, vous testez «Testable» plutôt que «RealEntity», ce qui va à l'encontre de toute l'idée des tests unitaires. –

+0

Dire "défait toute l'idée des tests unitaires" est extrême. L'option que j'ai proposée est une solution de contournement pour un problème commun rencontré lors de l'utilisation de nhibernate, ou toute autre chose qui définit des propriétés avec des setters non publics utilisant une classe proxy (ou réflexion). Sous-classer la classe sous test comme je propose émule ce que nhibernate fait avec proxy dynamique de sorte que l'instance peut être mise dans un état comme si elle était hydratée par nhibernate, et laisse tous les autres comportements inchangés. Ce n'est pas idéal et j'ai hâte d'entendre des alternatives, mais c'est faisable. – mattk