Pruebas unitarias con código dependiente de la red

Question

Estoy tratando de mejorar en las pruebas unitarias de mi código, pero ahora mismo estoy escribiendo mucho código que trata con sistemas remotos.SNMP, WMI, ese tipo de cosas.Con la mayoría de las clases puedo simular objetos para probarlos, pero ¿cómo se maneja la prueba unitaria de un sistema real?Por ejemplo, si mi clase sale y obtiene el objeto Win32_LogicalDisk para un servidor, ¿cómo podría realizar una prueba unitaria?

Answer 1

Suponiendo que quisiste decir "¿Cómo puedo realizar pruebas con cosas que son difíciles o imposibles de burlar?":

Si tiene una clase que "sale y obtiene el objeto Win32_LogicalDisk para un servidor" Y hace algo más (consume el objeto 'Win32_LogicalDisk' de alguna manera), asumiendo que desea probar las partes de la clase que consumen este objeto, puedo usar Inyección de dependencia para permitirle burlarse del objeto 'Win32_LogicalDisk'.Por ejemplo:

class LogicalDiskConsumer(object):

    def __init__(self, arg1, arg2, LogicalDiskFactory)
        self.arg1=arg1
        self.arg2=arg2
        self.LogicalDisk=LogicalDiskFactory()

    def consumedisk(self):
        self.LogicalDisk.someaction()

Luego, en el código de prueba de su unidad, pase un 'LogicalDiskFactory' que devuelva un objeto simulado para 'Win32_LogicalDisk'.

Answer 2

La forma más fácil de probar cosas que son difíciles de burlar es refactorizar el código de manera que su código (lógica que vale la pena probar) esté en un lugar y otras cosas que su código usa estén en módulos separados.El módulo es fácil de burlar y de esta manera puede concentrarse en su lógica empresarial.

Answer 3

Puede crear un conjunto de "códigos auxiliares de prueba" que reemplacen las rutinas principales de la biblioteca y devuelvan valores conocidos, quizás después de retrasos adecuados.

Como ejemplo, recientemente necesité desarrollar código para ejecutarlo dentro de un producto de terceros.El desafío era que nuestro "socio" haría la compilación e integración con su código base:no me permitieron mira a su código en cualquier forma!Mi estrategia fue construir un emulador muy simple que hiciera lo que yo pensamiento su código lo hizo, basándose en información de sus ingenieros.Usamos un lenguaje que facilitó el cambio de varias piezas del emulador dentro y fuera de cada compilación, por lo que pude realizar una gran cantidad de pruebas antes de involucrar a nuestro socio para crear cada nueva iteración.

Volvería a utilizar el mismo método, ya que los problemas de software en ese producto en particular son aproximadamente un orden de magnitud menores que en nuestro siguiente producto más confiable.