Note the method above doesn't let you change things at runtime. Though perhaps
you could use the `patchFile` pattern with some `when` statements and some
tedious usage of `include` you could potentially mock the core api's
differently by setting different `var opt {.compileTime.}` values, etc. But
that'd be annoying to write mocks in one file and tests in another but it could
work.
Another pattern would be something like:
# file: fooMock.nim
template mockedFooTmpl(a, b: untyped): untyped =
mockedFoo(a, v)
proc foo(a: int, b: int): int =
result = mockedFooTmpl(a, b)
Run
Then in your unit test:
# file: testFoo.nim
suite "basic tests":
test "essential lies":
proc mockedFoo(a, b: int): int =
result = 34 # break api
check foo(10, 100) == 34
test "essential truths":
proc mockedFoo(a, b: int): int =
result = a * b
check foo(10, 100) == 1_000
Run
I've done something like the above and it got fiddly with compiler when mocking
template's of templates... but for simpler proc's it seemed to work well
enough. Though it wasn't as split out into mocked modules.
Really, I'm not 100% on understanding the scoping rules of the `mockedFooTmpl`
above. The manual points out [mixin
statements](https://nim-lang.org/docs/manual.html#generics-mixin-statement) to
help say a symbol like `mockedFoo` would be "open". Perhaps it could be put
into a library to ensure it was setup so it'd be easier to do and the open vs
closed symbols could be more reliably handled.
