# Is Mocking discouraged? I would like to isolate testing
**URL:** https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549
**Category:** New to Julia
**Created:** [April 18, 2021, 3:53pm UTC](https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549 "2021-04-18T15:53:35Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@s-kap](https://discourse.julialang.org/u/s-kap)
#### Post date: [April 18, 2021, 3:53pm UTC](https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549/1 "2021-04-18T15:53:35Z")
EDIT: SimpleMock.jl allows mocking without needing macros in the live code, unlike Mocking.jl
Let’s say I have 2 modules (e.g. below) and I want to test out ModuleB in an isolated way; i.e. without running the code in ModuleA.
Is there a way to mock out or patch `ModuleA` when I unit test `ModuleB` ? If not, what are some alternative testing strategies I could use?
```julia
module ModuleA
function f_a()
println(1)
end
end
module ModuleB
import Main: ModuleA
function g()
ModuleA.f_a()
end
end
```
I’m coming from Python, where it’s common to mock calls from other files and instead just assert that the other file was called, instead of actually calling it.
---
### Author:  [@Per](https://discourse.julialang.org/u/Per)
#### Post date: [April 18, 2021, 4:24pm UTC](https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549/2 "2021-04-18T16:24:52Z")
I have never seen it used, but making an object that spits out mock functions is not hard.
```julia
struct Mock end
Base.getproperty(::Mock, s::Symbol) = (args...) -> println("Mock call to ", s, "(", join(repr.(args), ", "), ")")
const ModuleA = Mock()
ModuleA.f_a()
```
---
### Author:  [@Skoffer](https://discourse.julialang.org/u/Skoffer)
#### Post date: [April 18, 2021, 4:36pm UTC](https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549/3 "2021-04-18T16:36:47Z")
May be you need something like this : [GitHub - invenia/Mocking.jl: Allows Julia function calls to be temporarily overloaded for purpose of testing](https://github.com/invenia/Mocking.jl)
---
### Author:  [@tk3369](https://discourse.julialang.org/u/tk3369)
#### Post date: [April 18, 2021, 4:37pm UTC](https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549/4 "2021-04-18T16:37:40Z")
There are several options for Julia mocking libraries:
[https://github.com/invenia/Mocking.jl](https://github.com/invenia/Mocking.jl)
[https://github.com/JuliaTesting/SimpleMock.jl](https://github.com/JuliaTesting/SimpleMock.jl)
[https://github.com/tk3369/Pretend.jl](https://github.com/tk3369/Pretend.jl)
---
### Author:  [@jzr](https://discourse.julialang.org/u/jzr)
#### Post date: [April 18, 2021, 7:01pm UTC](https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549/5 "2021-04-18T19:01:11Z")
I would avoid mocking whenever possible. Design your program in a _functional_ style so that any I/O is on the outside and you can test the body of your program without substituting anything. When you need to do I/O to test against a web service, try to use the actual web service’s test endpoint unless it’s too slow. At that point you can make a fake `FakeClient` that behaves just like `RealClient` but faster – still saving data, just in memory instead of over the net. _Not_ tracking method calls like some mocks would.
---
### Author:  [@Impressium](https://discourse.julialang.org/u/Impressium)
#### Post date: [April 18, 2021, 7:39pm UTC](https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549/6 "2021-04-18T19:39:36Z")
I’m doing something like this:
```julia
function _input_f()
return data
end
function _output_f(data)
end
function logic(
p1, p2;
inpit_data = _input_f(),
output_f = _output_f()
)
result = do_stuff_without_side_effects(p1, p2, inpit_data)
output_f(result)
end
```
That’s very easy to test. Are there any disadvantage in that style?
---
### Author:  [@s-kap](https://discourse.julialang.org/u/s-kap)
#### Post date: [April 19, 2021, 7:05am UTC](https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549/7 "2021-04-19T07:05:31Z")
Thanks! It looks like SimpleMock provides the cleanest tests since it doesn’t require modifications to the live code
---
### Author:  [@s-kap](https://discourse.julialang.org/u/s-kap)
#### Post date: [April 19, 2021, 7:08am UTC](https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549/8 "2021-04-19T07:08:00Z")
This would redefine ModuleA, and I would also want to test the un-replaced ModuleA at some point
---
### Author:  [@Ken\_Williams](https://discourse.julialang.org/u/Ken_Williams)
#### Post date: [April 12, 2024, 3:38pm UTC](https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549/9 "2024-04-12T15:38:09Z")
Hello from the future, where this discussion seems to be the #1 Google result for “julia test mock”.
> [@tk3369](#):
>
> There are several options for Julia mocking libraries:
> …
For the three libraries mentioned by @tk3369 above, it looks like only `Mocking.jl` remains at least a semi-active project. `SimpleMock.jl`’s README says it’s broken for modern versions of Julia, and `Pretend.jl` looks like it hasn’t been touched in four years, though that doesn’t necessarily imply there’s anything wrong with it.
Also:
> [@jzr](#):
>
> I would avoid mocking whenever possible. Design your program in a _functional_ style so that any I/O is on the outside and you can test the body of your program without substituting anything. When you need to do I/O to test against a web service, try to use the actual web service’s test endpoint unless it’s too slow. At that point you can make a fake `FakeClient` that behaves just like `RealClient` but faster – still saving data, just in memory instead of over the net. _Not_ tracking method calls like some mocks would.
Not all mocking is for network isolation purposes. For me, the biggest use case is something like “conditional verification”, where I want to test `ModuleB`, which internally calls `ModuleA`, _under the conditional assumption_ that `ModuleA` is known to work properly, and/or returns a given result quickly.
In many cases I agree that it’s inappropriate to care how `ModuleB` achieves its results, it’s a black box, and the fact that it uses `ModuleA` internally is an implementation detail. But in other cases, for lots of different reasons, it’s very helpful to call that a “grey box” that can be marginalized over for testing purposes.
---
### Author:  [@bertschi](https://discourse.julialang.org/u/bertschi)
#### Post date: [April 12, 2024, 6:03pm UTC](https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549/10 "2024-04-12T18:03:19Z")
> [@Ken\_Williams](#):
>
> Not all mocking is for network isolation purposes. For me, the biggest use case is something like “conditional verification”, where I want to test `ModuleB`, which internally calls `ModuleA`, _under the conditional assumption_ that `ModuleA` is known to work properly, and/or returns a given result quickly.
Just some thoughts …
- If `ModuleB` relies on `ModuleA` it also relies on the correctness of it, i.e., conditional testing might debugging easier – because you know where to look for the failure – but is not enough in its own.
- If the coupling between `ModuleB` and `ModuleA` is not as strong in the first place, i.e., it just happens to use some functions from `ModuleA`, but could just as well work with a different backend, it should probably restructured to rely on an abstract interface instead. Julia is especially nice in this respect and as soon as an abstract interface has been identified mocking becomes trivial – by just implementing some mock code adhering to the interface.
---
### Author:  [@Ken\_Williams](https://discourse.julialang.org/u/Ken_Williams)
#### Post date: [April 15, 2024, 1:52pm UTC](https://discourse.julialang.org/t/is-mocking-discouraged-i-would-like-to-isolate-testing/59549/11 "2024-04-15T13:52:52Z")
> [@bertschi](#):
>
> - If `ModuleB` relies on `ModuleA` it also relies on the correctness of it, i.e., conditional testing might debugging easier – because you know where to look for the failure – but is not enough in its own.
There’s not just one right answer. Sometimes I need to test `ModuleB` end-to-end, sometimes I need to test it conditionally on what `ModuleA` is providing, sometimes both.