There’s also Mimic — Mimic v2.3.0. I haven’t tried it yet though.
dimitarvp
krasenyp
Generally, a mocked function comes with expectations which form a specification of how the function is going to be called. Stubs, on the other hand, only provide predefined answers to calls and, in my experience, doesn’t lead to testing calling logic which shouldn’t matter most of the times.
3
jc00ke
Your build/1 function is begging for an integration test because it “speaks to the outside world” (even though it’s the local file system.)
You could consider using fixture files, where one is valid and one is invalid, and you could assert accordingly.
Even though this post is about Ruby, I like the “Don’t mock what you don’t own” philosophy and I’ve happily used it in Elixir. I’d argue that you don’t “own” File.
Another option would be to inject the File.read/1 dependency, so your function could change as such:
- def build(file_name) do
+ def build(file_name, opts \\ []) do
+ reader = opts[:reader] || &File.read/1
file_name
- |> File.read()
+ |> reader.()
|> process_file_result()
end
(I just hand-wrote that diff above, please excuse any errors)
Sometimes I use DI because it’s more convenient, but I think in this specific example I’d personally opt for the fixture files.
2
kenny-evitt
I’ve found that it’s occasionally useful to move a private function that I want to test to an ‘internal module’, e.g. FizzBuzz.FileProcessing. That seems to be pretty clear on its own but you can, of course, also make it explicit with a suitable module-doc:
defmodule FizzBuzz.FileProcessing
@moduledoc """
This is an internal module for `FizzBuzz`.
"""
...
I’ve also found that it’s often fine – good even – to just use a test file, i.e. “read from my filesystem”.
2
