Suponga que he decidido escribir una aplicación grande en C, o en cualquier otro lenguaje de programación procesal. Tiene funciones con dependencias de llamadas que se ven así:

A
|
+-------------+
|             |
B1            B2
|             |
+------+      +------+
|      |      |      |
C11    C12    C21    C22

bviamente, la prueba unitaria de las funciones de hojas, C11, C12, C21 y C22 es muy fácil: configure las entradas, invoque las funciones, confirme las salidas.

Pero cuál es la estrategia adecuada para permitir una buena prueba de unidad para B1, B2 y A?

HaríaInyección de dependenci sugerir queB1 (yB2 también) se declarará como sigue?

// Declare B1 with dependency injection for invoking C11 and C12.
int B1(int input, int (*c11)(int), int(*c12)(int));

Pero esa estrategia no parece escalable si tengo muchas capas de llamadas. Solo imagina cuál es la declaración paraA se vería así:

int A(int input, int (*b1)(int, int (*)(int), int(*)(int)), 
                 int(*b2)(int, int (*)(int), int(*)(int)),
                 int (*c11)(int),
                 int (*c12)(int),
                 int (*c21)(int),
                 int (*c22)(int));

Yuck! Tiene que haber una mejor manera

A veces, creo que DI y otros patrones similares que pretenden promover la modularidad y la facilidad de mantenimiento en realidad obstaculizan la claridad del código y complican lo que debería ser una codificación directa en abstracciones sin sentido e indirectas intrincadas.

¿Cómo los grandes proyectos de software en C, como Perl y Ruby, se ocupan de las pruebas unitarias?