Comment tester les commandes du serveur asp.net

Question

Nous avons développé un certain nombre de contrôles serveur ASP.Net et nous devons les tester. Je veux instancier un contrôle, définir des propriétés, appeler CreateChildControls et tester la hiérarchie de contrôle.

Je cours dans un certain nombre de problèmes:

1. Les contrôles se fondent sur HttpContext
2. CreateChildControls est privé

Même en ajoutant un seul contrôle enfant à la collection de contrôles appelle les ResolveAdapter() méthode qui repose sur HttpContext.

Comment puis-je contourner le problème?

p.s. Je ne souhaite pas tester les contrôles sur une page (!).

Answer 1

Cela ressemble beaucoup au fait que vous ne vous souciez pas du rendu réel du contrôle, mais plutôt de la logique contenue dans le contrôle. Pour cela je suggère que vous avez un autre problème en plus de l'impossibilité de tester le contrôle en dehors de HttpContext. Si la logique ne concerne que le contrôle, vous devez faire confiance au framework pour faire son travail et laisser tomber le contrôle sur une page pour voir si cela fonctionne correctement. Si la logique que vous essayez de tester est la logique métier, vous devez refactoriser.

Extrayez la logique métier dans un projet/Dll séparé, et pensez à implémenter un MVP pattern avec votre contrôle serveur. Vous n'avez pas à aller avec un gros cadre lourd comme WCSF non plus. Conceptuellement, vous pouvez mettre en œuvre ceci avec peu d'effort.

Créer une interface qui représente les valeurs de votre point de vue:

public interface IOrderView 
{ 
    Int32 ID{get; set;} 
    String Name{get; set;} 
    List<Item> Items {set;} 
} 

Une fois que cela est défini, vous avez besoin d'un présentateur qui exerce ce point de vue:

public class OrderPresenter 
{ 
    public IOrderView View {get; set;} 

    public void InitializeView() 
    { 
     //Stuff that only happens when the page loads the first time 

     //This is only for an example: 
     var order = Orders.GetOrder(custId); 

     View.ID = order.ID; 
     View.Name = order.Name; 
     View.Items = order.Items; 
    } 

    public void LoadView() 
    { 
     //Stuff that happens every page load 
    } 
} 

Maintenant, votre contrôle serveur peut mettre en œuvre cette l'interface utilisateur, et lui-même initialiser avec le OrderPresenter

public class OrderControl: Panel, IOrderView 
{ 
    private OrderPresenter Presenter{get; set;} 

    public OrderControl() 
    { 
     //Create new presenter and initialize View with reference 
     // to ourselves 
     Presenter = new OrderPresenter{View = this;} 
    } 

    protected override void OnLoad(EventArgs e) 
    { 
     if(Page.IsPostback) 
     { 
      _presenter.InitializeView(); 
     } 

     _presenter.LoadView(); 

     //Other normal onload stuff here... 
    } 

    //Now for the interface stuff 
    public Int32 ID 
    { 
     get{ return Int32.Parse(lblOrderId.Text); } 
     set{ lblOrderId.Text = value.ToString(); } 
    } 

    public String Name 
    { 
     get{ return lblOrderName.Text; } 
     set{ lblOrderName.Text = value; } 
    } 

    public List<Item> Items 
    { 
     set 
     { 
      gvItems.DataSource = value; 
      gvItems.DataBind(); 
     } 
    } 
} 

Et voilà! Vous devriez être en mesure d'écrire des tests unitaires contre le OrderPresenter maintenant en utilisant une View stubbed out. Aucun HttpContext requis, et vous avez une séparation plus propre des préoccupations. Si vous avez déjà toute votre logique métier séparée, je m'excuse, mais je ne vois pas d'autre raison pour tester un contrôle serveur en dehors du runtime ASP.Net en plus de devoir vérifier la logique métier réelle. Si ce est le cas, alors je vous encourage fortement à refactoriser maintenant avant que vous réalisiez le cauchemar d'entretien cela causera finalement par Leaky Abstractions.