Pruebas unitarias con código dependiente de la red

Question

Estoy tratando de mejorar la prueba unitaria de mi código, pero ahora estoy escribiendo un montón de 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 manejan las pruebas unitarias de un sistema real? Por ejemplo, si mi clase se apaga y obtiene el objeto Win32_LogicalDisk para un servidor, ¿cómo podría probarlo?

Answer 1

Suponiendo que quería decir "¿Cómo se prueba contra las cosas que son difíciles/imposible burlarse":

Si usted tiene una clase que "se apaga y se pone el objeto Win32_LogicalDisk para un servidor" y no hace otra cosa (consume el objeto 'Win32_LogicalDisk' de alguna forma), suponiendo que desea probar las piezas de la clase que consume este objeto, puede usar Dependency Injection para permitirle simular el 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() 

en su código de prueba de unidad, sucedió entonces en un 'LogicalDiskFactory' que devuelve un objeto de burla para la 'Win32_LogicalDisk'.

Answer 2

Puede crear un conjunto de "comprobantes de prueba" que reemplacen las rutinas de la biblioteca central y devuelvan los valores conocidos, tal vez después de las demoras adecuadas.

Como ejemplo, recientemente tuve que desarrollar código para ejecutar dentro de un producto de terceros. El desafío era que nuestro "socio" estaría haciendo la compilación e integración con su código base: ¡No podía mirar su código de ninguna forma! Mi estrategia era construir un emulador muy simple que hiciera lo que yo pensaba pensó su código, según la 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 hacer una gran cantidad de pruebas antes de involucrar a nuestro socio para compilar 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 próximo producto más confiable.

Answer 3

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