Suppose I\'ve decided to write a large application in C, or any other procedural programming language. It has functions with call-dependencies that look like this:
you can put the dependencies to a c-struct that will become one parameter for the function call. in c this would be similar to the file api where the first parameter is always the file-handle
If you only require the DI for unit testing you may use the linker to do it.
What I mean is that the functions B1 & B2 are declared in a header and used by function A, so the implementation of the B functions is provided by the linker. You just need to provide a different C-File for unit tests. This should not be a big problem, as you probably have your own makefile for the unit test anyhow.
If you require dynamic dependency resolution at runtime you should use a factory pattern (a function returning the function-pointer) for function pointers and pull them from the factory when required. The factory may decide depending on global context what function to return.
I like this question. It gets a bit tricky in procedural languages.... but I think you can borrow an idea from the OO world where folks often use constructor overloading to handle some of the DI work. So for example you would use the default constructor that sets up all the dependencies as usual... but then also have another constructor that allows the dependencies to be injected.
Since you are procedural... I think you could use function overloading to handle this for you. Also when you are testing you only would need to mock out B1 & B2 when calling A... so you could simplify your DI for that purpose. In other words if you really only using DI for unit testing then you don't have to inject the whole tree of dependcies only the first level dependecies...
So from A you might have...
int A(int input){
// create function point to b1 & b2 and call "return A(input, {pointer to b1},{pointer to b2})"
}
forgive my psuedo code it has been a long time since I did C.
A
only needs to call B1
and B2
. It does not need to know about anything at the C level.
You could inject a different dummy versions of functions B1
and B2
into A
for the purpose of testing A
.
This isolates A
from needing the whole structure and means you can test each function in isolation.
You can do proper unit testing of B1, B2 and A without DI. Just like the leaf functions, B1 and B2 has valid inputs and outputs, and you test those, same with A. That B1 can use C11 and C12 internally to help you fulfill its unit tests doesn't mean they have to be injected in cases where you don't need that flexibility.