¿Seguir el TDD conduce inevitablemente a DI?

14

Aprendí a hacer el desarrollo guiado por pruebas (TDD), la inyección de dependencia (DI) y la inversión de control (IoC) al mismo tiempo. Cuando escribo código usando TDD, siempre termino usando DI en los constructores de mi clase. Me pregunto si esto se debe a cómo aprendí a hacer TDD, o si esto es un efecto secundario natural de TDD.

Entonces, mi pregunta es la siguiente: ¿el hecho de seguir a los directores de TDD y escribir pruebas unitarias que no dependen de servicios externos conduce inevitablemente a la DI?

    
pregunta Gilles 15.08.2012 - 16:55
fuente

5 respuestas

19
  

¿Las siguientes pruebas unitarias de TDD y de escritura que no dependen de bases de datos o servicios externos llevan inevitablemente a DI?

Para definiciones amplias de DI, si. Las clases no existen en un vacío, por lo que deben llenar sus dependencias de alguna manera. A veces solo proporcionar un valor está bien. A veces es necesario proporcionar un simulacro en el constructor. A veces a través de contenedores IoC. A veces a través de prueba privada de acceso. Todo está inyectando algo de prueba en la clase para que pueda funcionar de forma aislada.

    
respondido por el Telastyn 15.08.2012 - 17:05
fuente
9

Para las personas que ya conocen DI, pero que nunca han visto el punto, creo que las pruebas unitarias casi invariablemente conducirán a usar DI.

Si no sabe de DI y está tratando de escribir pruebas unitarias, algunas personas reinventarán naturalmente la DI, otras se frustrarán y eventualmente descubrirán la DI a través de la investigación, pero se sorprenderá con qué frecuencia simplemente no se le ocurrirá a alguien que podría haber una mejor manera de diseñar su software para facilitar las pruebas unitarias. Esas personas descartan las pruebas de unidad como intratables y se rinden.

    
respondido por el Karl Bielefeldt 15.08.2012 - 18:13
fuente
8

La prueba de la unidad llevará a DI (ya que te obliga a crear unidades acopladas libremente). TDD no necesariamente, ya que TDD también se puede usar para crear pruebas capa por capa, en lugar de pruebas de unidad "textuales". Ver este artículo

enlace

para una explicación de las diferencias.

    
respondido por el Doc Brown 15.08.2012 - 20:56
fuente
3

Sí y no: TDD lleva a escribir código bien estructurado, que a su vez conduce a DI.

Con esto quiero decir que TDD generalmente te envía el camino correcto con respecto a la encapsulación, SRP y reutilización. No se trata solo de hacer algunas pruebas alrededor de su código: se trata de usar esas pruebas para desarrollar un mejor diseño. Si un objeto crea sus propias dependencias, entonces vive dentro de un contexto específico dentro de una aplicación específica y es probable que se incluya en la aplicación en mayor grado. DI es algo bueno, no solo desde el punto de vista de las pruebas, sino también desde el punto de vista de la calidad del código.

    
respondido por el Tim 15.08.2012 - 18:08
fuente
0

Como ya se señaló en otras respuestas, TDD no requiere pruebas de unidad . También puedes escribir pruebas de integración / funcionales mientras haces TDD. De las varias formas de aplicar TDD, la creación de pruebas unitarias sería la forma "falsificar hasta que se logre" (consulte el libro de Kent Beck para obtener más información).

En cuanto a "TDD inevitablemente conduce a DI", definitivamente no lo hace. Lo que se necesita al escribir pruebas unitarias es aislar la unidad que se está probando a partir de las implementaciones de sus dependencias externas. Y esto se puede hacer con la misma facilidad con o sin DI. La mejor manera, probablemente, es usar una herramienta adecuada de aislamiento / burla.

    
respondido por el Rogério 31.01.2014 - 21:47
fuente

Lea otras preguntas en las etiquetas