Pruebas de unidad con el patrón de Mediador - Todos privado a lo público

Question

Estoy utilizando el patrón de mediador para facilitar la prueba de la unidad de objetos de GUI.

código psudo Ejemplo:

Class MyGuiClass
{
  //...  Declare and initialize mediator to be a MyMediator
  private void On_SomeButtonPressed()
  {
     mediator.SomeButtonWasPressed();
  }
}

Class MyMeditator
{
  public void On_SomeButtonPressed()
  {
     //.. Do something now that the button was pressed
  }

}

Esto es bueno porque ahora puedo prueba de la unidad lo que sucede cuando se presiona SomeButton sin tener que crear una ventana.

Mi preocupación es que he tomado un método que era privado y lo hizo público para cualquiera que hace un mediador para llamar. Pasado veces he hecho esto no me importó porque yo no tenía muchos métodos que tenía que hacer pública.

Actualmente estoy refactorización una clase muy grande para utilizar este modelo y me pregunto si hay alguna manera puedo controlar la visibilidad de quién puede hacer una MyMediator o qué clases de algunos de los métodos son públicos para. (Esto puede no ser posible, o incluso necesario, pero pensé que iba a preguntar.)

(estoy usando C # 3.0 con .NET 3.5 SP1)

Answer 1

El punto es que desea la interfaz pública de una clase para mostrar 'API' de esa clase pública, por lo que en la fabricación de los métodos públicos y privados que están haciendo la clase más confuso y menos 'limpia'?

Un par de cosas que puede hacer: 1) pensar a través de lo que realmente es la 'cara pública' de su mediador (o clase humilde objeto) y felizmente hacer esos métodos pública. Incluso si sólo se usan dentro del conjunto - que no forma parte de la cara pública de la asamblea - que está bien porque notificación de que su propia clase mediador no se declara público. Por lo que incluso sus métodos públicos siguen siendo interno para el montaje.

2) Se puede falsificar los soldados utilizando interno para uso privado (a continuación, establezca el atributo InternalsVisibleTo de la asamblea si sus clases de prueba se encuentran en un ensamblado independiente).

3) Tomar el enfoque de 'recuadro negro' de la unidad de pruebas mediante el cual, en principio, que no será necesario probar los soldados, ya que se hagan la prueba a través de su uso cuando se llama desde los métodos públicos.

Answer 2

Creo que no importa .. ¿Quién tiene una instancia del mediador, que no sea la interfaz gráfica de usuario? Si alguien lo hace, se va a llamar al método? Si es así, ¿importa? Va a ser difícil de notar, diagnosticar y corregir el error?

Creo que se puede lograr lo que busca con los eventos sin embargo:

por ejemplo.

/* in the gui class (view) */
public event EventHandler OnButtonClicked;

/* in the mediator */
public MyMediator(MyView view) 
{
    view.OnButtonClicked += HandleButtonClicked;
}

private void HandleButtonClicked(object sender, EventArgs e)
{

}

Answer 3

No está seguro sobre C #, pero en Java puede declarar algo tan acceso a nivel de paquete (en Java omitiendo el especificador de acceso). Lo que hago es crear una jerarquía de prueba independiente que es paralelo a la estructura de mi paquete, así que clase de prueba com.a.b.c.MyClass, voy a tener un com.a.b.c.MyClassTest clase de prueba, que luego pueden acceder legalmente a los métodos de acceso a paquete en MiClase.

No hago tan parecido a la idea de hacer todo lo público no sólo a causa de los problemas de acceso, sino porque estorba la interfaz - Prefiero la interfaz pública de la clase expresa lo lo hace, sin ¿Cómo lo hace, que es a menudo donde termino si expongo métodos preferiría ser privado.