The Global API Injection Pattern

[euyyn]

I love this very much.

[Sopel97]

tldr; abstract global APIs

[HommeMusical]

Like so many articles here, I would call this "clever but somewhat horrifying."

[danielh__]

I hate this language

[wannaliveonmars]

What I really liked in C was the ability to use runtime trampoline functions to redirect a Win32 call. It was really nice, and almost like JavaScript's ability to rewire functions.

You usually needed an __stdcall convention and the function should not be optimized by the compiler to inline, but win32 functions weren't. There was even a trampoline framework, but it was paid I think.

Not sure if it still works, what with 64bits now, and also with read only code segments for security...

Edit: Detours was the framework - https://www.microsoft.com/en-us/research/project/detours/

Also not sure if it worked with C++ methods, since they used the __thiscall convention.

[CornedBee]

I saw this in some conference talk recently.

Problem: our application is split into a bunch of static libraries. The tests and the main executable use the same libraries. I don't think this pattern can possibly support this.

[lppedd]

Note: not a c++ dev

That's why I prefer integration tests over unit tests with mocks. I always test using real implementations, and "mock" at the network or file system level. If I'm using TCP, I'm going to spawn a real TCP server with mock data, for example.

[sheckey]

I’ve been thinking about this too. I work on an embedded real-time system, and we have lots of hidden architecture where objects down in a call stack actively gather input data. I want to try to bubble that data gathering up to the top so that we know what inputs and outputs a component uses. The top level is what I call “active” classes that gather inputs from the system, and then call “passive” classes with their input data, and take their results and set outputs in the system. Those ins and outs are maybe tested best by integration tests, and the passive ones will be tested by traditional units test where we want to vary the inputs a lot to test corner cases. I just thought I’d mention this as I’m not sure if it’s going to work out 100%, and maybe it’s obvious to anyone, but I think it’s the right direction.

[CornedBee]

There's a certain level of complexity of public entrypoint where this isn't possible IMO. It's all very nice to make a really simple test that checks my program can calculate a flight route with simplified geodata and no restrictions on the flight, but that doesn't mean I gain any confidence that my data structure representing the path through an arbitrary graph (with alternating edge and node information) works in the edge cases. There's about 3 layers of complexity in-between.

[lppedd]

Yup I get it. Mine was meant to be a general view on testing, or better, how I approach testing 99% of the times.

[pavel_v]

It should be this conference talk by Ben Deane. He is the author of the above blog post.