Pregunta

Tengo una clase con cálculos científicos complejos. Está configurado para permitir solo a un usuario crear un caso correctamente instanciado. Sin embargo, para probar el código correctamente, se requiere establecer variables de estado internas directamente, ya que los documentos de referencia proporcionan estos datos en sus casos de prueba. Sin embargo, si se hace incorrectamente, puede invalidar el estado.

Por lo tanto, debo tener la capacidad, una función miembro, de establecer variables internas de los programas de prueba unitaria. Pero quiero desalentar fuertemente que los usuarios normales llamen a esta función. (Sí, un usuario determinado puede muck con cualquier cosa ... pero no quiero anunciar que hay una manera de hacer algo mal ).

Sería bueno poder decirle a Intellisense que no muestre la función, por ejemplo.

La mejor solución que tengo en este momento es simplemente nombrar la función algo así como: DangerousSet ().

¿Qué otras opciones tengo?

Seguir-Up

Encontré la respuesta de David B más útil para mi situación. Gracias!
La sugerencia de Mufasa de usar la reflexión fue genial, pero más difícil de implementar (para mí).
La sugerencia de Chris de usar un decorador fue buena, pero no funcionó.
La sugerencia de BFree sobre XML también es buena y ya estaba en uso, pero realmente no resuelve el problema.

Finalmente, la sugerencia de BillTheLizard de que el problema está en los documentos de origen no es algo que pueda controlar. Expertos internacionales publican libros altamente técnicos y artículos de revistas para uso de su comunidad. El hecho de que no aborden mis necesidades particulares es un hecho de la vida. Simplemente no hay documentos alternativos.

¿Fue útil?

Solución

Suponga que desea probar este objeto manipulando sus campos.

public class ComplexCalculation
{
    protected int favoriteNumber;
    public int FavoriteNumber
    {
        get { return favoriteNumber; }
    }
}

Coloque este objeto en su ensamblaje de prueba / espacio de nombres:

public class ComplexCalculationTest : ComplexCalculation
{
    public void SetFavoriteNumber(int newFavoriteNumber)
    {
        this.favoriteNumber = newFavoriteNumber;
    }
}

Y escribe tu prueba:

    public void Test()
    {
        ComplexCalculationTest myTestObject = new ComplexCalculationTest();
        myTestObject.SetFavoriteNumber(3);
        ComplexCalculation myObject = myTestObject;

        if (myObject.FavoriteNumber == 3)
            Console.WriteLine("Win!");

    }

PD: Sé que dijiste interno , pero no creo que quisieras decir internal .

Otros consejos

Puede usar InternalsVisibleToAttribute para marque los miembros internos como visibles para su conjunto de prueba. Parece brillar cuando se usa en este contexto, aunque no es exactamente "amigo".

  1. Marque su función DangerousSet interna en lugar de public.

  2. En Properties \ AssemblyInfo.cs del proyecto que contiene DangerousSet :

    [assembly:InternalsVisibleTo("YourTestAssembly")?

Si tiene dos ensamblajes de prueba por cualquier motivo, la sintaxis es:

[assembly:InternalsVisibleTo("TestAssembly1"), 
    InternalsVisibleTo("TestAssembly2")]

Decora tu método con este atributo:

[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]

Esto lo ocultará de Intellisense.

EDITAR:

Pero aparentemente esto tiene una advertencia bastante significativa: " En Visual C #, EditorBrowsableAttribute no suprime miembros de una clase en el mismo ensamblaje. " a través de MSDN .

Parece que su verdadero problema está en sus documentos de referencia. No debe probar casos que son imposibles de encontrar con el uso adecuado de su clase. Si a los usuarios no se les debe permitir cambiar el estado de esas variables, tampoco deberían hacerlo sus pruebas.

También puedes usar la reflexión. La búsqueda de Google apareció Unidad que prueba métodos privados utilizando la reflexión .

¿Puede su código de prueba incluir una subclase de la clase de cálculos? Si es así, puede marcar la función protected y solo los herederos podrán usarla. Estoy bastante seguro de que esto también lo quita del intellisense, pero podría estar equivocado al respecto.

Lo que he hecho en el pasado es colocar los Comentarios XML por el método y usar la sección para escribir en letras grandes en negrita. NO USE ESTE MÉTODO o lo que sea. De esa manera, si alguien intentara usarlo, Intellisense les daría una buena advertencia.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top