Método de prueba de unidad que usa controles de IU

Question

Actualmente estoy escribiendo algunos métodos que hacen algunas operaciones básicas en los controles de formulario, por ejemplo, Textbox, Groupbox, estas operaciones son genéricas y se pueden usar en cualquier aplicación.

Empecé a escribir algunas pruebas unitarias y me preguntaba si debería usar los controles de formulario reales que se encuentran en System.Windows.Forms o debería simular las secciones que estoy tratando de probar. Así, por ejemplo:

Decir que tengo este método que se lleva un control y si se trata de un cuadro de texto que se borrará la propiedad de texto como este:

 public static void clearall(this Control control) 
     { 
      if (control.GetType() == typeof(TextBox)) 
      { 
       ((TextBox)control).Clear(); 
      } 
     } 

entonces quiero probar este método de manera que haga algo de esta manera:

 [TestMethod] 
     public void TestClear() 
     { 
      List<Control> listofcontrols = new List<Control>(); 
      TextBox textbox1 = new TextBox() {Text = "Hello World" }; 
      TextBox textbox2 = new TextBox() { Text = "Hello World" }; 
      TextBox textbox3 = new TextBox() { Text = "Hello World" }; 
      TextBox textbox4 = new TextBox() { Text = "Hello World" }; 

      listofcontrols.Add(textbox1); 
      listofcontrols.Add(textbox2); 
      listofcontrols.Add(textbox3); 
      listofcontrols.Add(textbox4); 

      foreach (Control control in listofcontrols) 
      { 
       control.clearall(); 
       Assert.AreEqual("", control.Text); 
      } 
     } 

¿Debo añadir un referance System.Window.Forms a mi unidad de prueba y utilizar el objeto de cuadro de texto real? o lo estoy haciendo mal?

NOTA: El código anterior es solo un ejemplo, no lo compilé ni lo ejecuté.

Answer 1

Si está intentando probar la lógica de la aplicación mediante la simulación de la interacción con los controles de la interfaz de usuario, debe hacer algo de abstracción usando el MVC pattern. Luego, puede tener una vista de talón y llamar a los métodos del controlador desde las pruebas de su unidad.

Si son los controles reales que está intentando probar la unidad, me tiene a mí.

Answer 2

Lo que estás sugiriendo no compilará si tu código depende de System.Windows.Forms.Control. Su versión de Control y Textbox son simplemente del tipo incorrecto.

Si, en cambio, que se separó de su interfaz de usuario y la lógica con interfaces, entonces se podría hacer esto ... Algo como esto:

public interface ITextBox 
{ 
    public string Text {get; set;} 
} 

public class TextBoxAdapter : ITextBox 
{ 
    private readonly System.Windows.Forms.TextBox _textBox; 
    public TextBoxAdapter(System.Windows.Forms.TextBox textBox) 
    { 
     _textBox = textBox; 
    } 

    public string Text 
    { 
     get { return _textBox.Text; } 
     set { _textBox.Text = value; } 
    } 
} 

public class YourClass 
{ 
    private ITextBox _textBox; 
    public YourClass(ITextBox textBox) 
    { 
     _textBox = textBox; 
    } 

    public void DoSomething() 
    { 
     _textBox.Text = "twiddleMe"; 
    } 
} 

Luego, en su prueba, todo lo que tiene que hacer es crear una simula, falsifica o resuelve ITextBox y lo pasa.

Cuando hago algo como esto, creo una interfaz en un nivel ligeramente superior ... Creo una interfaz que se parece mucho a la interfaz de usuario completa y tiene la interfaz de usuario implementar la interfaz. Entonces, puedo mover la IU todo lo que necesito, sin saber realmente que es un control de Formas.

Por cierto, si quieres ir con el enfoque de la creación de controles reales, considere esta entrada del blog sobre él: http://www.houseofbilz.com/archive/2008/10/12/winforms-automation-extensions.aspx

Answer 3

Hay varios patrones que son útiles para la separación de presentación de interfaz de usuario de la lógica de interfaz de usuario que incluye Modelo- View-Controller y las diversas encarnaciones de Model-View-Presenter (también conocido como Humble Dialog). Humble Dialog fue creado específicamente para facilitar las pruebas unitarias. Definitivamente debe tener uno de estos patrones de interfaz de usuario en su arsenal de diseño.

Pero he encontrado que, para formularios simples, cuando el framework lo admite, es bastante sencillo probarlo directamente con los controles de UI reales. He construido interfaces de usuario completamente robustas, completamente de prueba, en Java Swing y Windows.Forms. No pude manejarlo en SWT o ASP.NET y volví a MVP.

Para probar cosas como esta ...

[Test] public void ShouldCopyFromAvailableToSelectedWhenAddButtonIsCLicked(){ 
    myForm.AvailableList.Items.Add("red"); 
    myForm.AvailableList.Items.Add("yellow"); 
    myForm.AvailableList.Items.Add("blue"); 

    myForm.AvailableList.SelectedIndex = 1; 
    myForm.AddButton.Click(); 

    Assert.That(myForm.AvaiableList.Items.Count, Is.EqualTo(2)); 
    Assert.That(myForm.SelectedList.Items[0], Is.EqualTo("yellow")); 
} 

...trabajar directamente contra los controles de la interfaz de usuario funciona bien. Pero si desea comenzar a probar movimientos de mouse, pulsaciones de teclas o arrastrar y soltar, sería mejor que elija un patrón de interfaz de usuario más robusto como el sugerido por Brian.