3 ms·

I hope you see the irony in using “you’re holding it wrong” here? If real world use of a library tends to push towards a certain outcome that I dislike, I’m go

I hope you see the irony in using “you’re holding it wrong” here? If real world use of a library tends to push towards a certain outcome that I dislike, I’m going to tend to dislike that library. You’re also never going to convince me that creating an interface for a single implementation is the best way to facilitate unit testing. Mox is nothing more than a kludge to get around the limitations of the language and I think there are much less invasive kludges available. To be honest when I’m working with devs who are new to elixir I’m embarrassed when I have to explain how Mox works. >but in practice it's better to hardcode things rather than trying to make it generic and swappable the first time around. Junior devs have a tendency to over-engineer code "because we might need to change it later." My motto is "copy and paste it three times before adding a layer of abstraction" This I agree with 100%

gashcrab 3y ago
Could you share the less invasive kludges you’ve found? I share your frustration with Mox, although maybe not so passionately.
- sarchertech 3y ago
  I’ve had a good experience with Mimic for one.
sph 3y ago
> I hope you see the irony in using “you’re holding it wrong” here? Not really. If you use a hammer on a screw, is it the hammer's fault? Sounds like the code base you are working on is badly-organised, rather than Mox being the root of all evil. There are far too many stories of people picking up Elixir and coding in it as if it were Python or Ruby. You cannot base your experience with it on a codebase written by people new to functional languages. And no one forces you to use Mox, anyway. It's far from being a core Elixir component. It is just one implementation of the mock object pattern that comes on a standalone, optional library. > Mox is nothing more than a kludge to get around the limitations of the language Mocks are not an Elixir invention, and exist in pretty much all languages. https://en.wikipedia.org/wiki/Mock_object https://en.wikipedia.org/wiki/Mock_object
- sarchertech 3y ago
  “You’re holding it wrong” was a response from Steve Jobs blaming users for a design flaw. >Mocks are not an Elixir invention I have no problem with Mocks, I have a problem with Mox. Mox is the kludge, not Mocks in general.
goosejuice 3y ago
> You’re also never going to convince me Such confidence, how do you approach testing your clients? Personally I have never used Mox, but I read the originating blog post when it came out and have followed it's principles ever since.
- sarchertech 3y ago
  By either using Bypass, passing in fake adapters to Req, or injecting a dispatch layer at test time with Mimic. I’ve been doing this for 20 years, you’re definitely never going to convince me that an interface for a single implementation is the best way to create the dynamic dispatch you need for testing.
  - goosejuice 3y ago
    Bypass is a nice alternative if the client is what's under test. Often it's not. > passing in fake adapters to Req, or injecting a dispatch layer at test time with Mimic. I see, so you buy into DI for the purposes of testing but you prefer a more terse approach than what behaviours offer. The extra module never really bothered me and the contents are mostly what would go into the implementation anyway. LSP provides documentation all the same. > I’ve been doing this for 20 years, you’re definitely never going to convince me I certainly appreciate your input, I like to learn new things, but have little interest in trying to convince anyone that makes such a dogmatic statement. An unfortunate thing to hear from a principle developer. I hope your coworkers agree with you.
thibaut_barrere 3y ago
> Mox is nothing more than a kludge to get around the limitations of the language and I think there are much less invasive kludges available. To be honest when I’m working with devs who are new to elixir I’m embarrassed when I have to explain how Mox works. There are other ways, more similar to Ruby etc (e.g. https://github.com/edgurgel/mimic https://github.com/edgurgel/mimic, or with_mock etc). And also there is the risk to "over-mock", for sure. But a good middle ground brings the right value here!
- sarchertech 3y ago
  I’ve used mimic an I think it’s a much better option than Mox.
  - sph 3y ago
    We spoke about this topic for far too long today, but looking at Mimic and its "nothing is mocked unless I tell you to" design, it works only iff you are using mocks the wrong way and at the wrong boundaries.
    - sarchertech 3y ago
      There’s no reason you can’t setup your tests so that mimic stubs out your module or a subset of functions in your module everywhere where you don’t explicitly override it. The main difference is that the extra dispatch layer is only injected at test time, so there’s no extra indirection in the production code.
throwawaymaths 3y ago
> Mox is nothing more than a kludge to get around the limitations of the language and I think there are much less invasive kludges available. You're definitely using or setting up mox wrong. Mox is incredibly good: it lets you do things in elixir that you definitely can't do in other languages: concurrently running tests with different mocks.
- sarchertech 3y ago
  You can do that in every language I’ve worked with. You can even do it with Mimic in Elixir without the extra production indirection layer.
  - deleted 3y ago
    [deleted]

gashcrab 3y ago

Could you share the less invasive kludges you’ve found? I share your frustration with Mox, although maybe not so passionately.

sarchertech 3y ago
I’ve had a good experience with Mimic for one.

sph 3y ago

> I hope you see the irony in using “you’re holding it wrong” here? Not really. If you use a hammer on a screw, is it the hammer's fault? Sounds like the code base you are working on is badly-organised, rather than Mox being the root of all evil. There are far too many stories of people picking up Elixir and coding in it as if it were Python or Ruby. You cannot base your experience with it on a codebase written by people new to functional languages. And no one forces you to use Mox, anyway. It's far from being a core Elixir component. It is just one implementation of the mock object pattern that comes on a standalone, optional library. > Mox is nothing more than a kludge to get around the limitations of the language Mocks are not an Elixir invention, and exist in pretty much all languages. https://en.wikipedia.org/wiki/Mock_object https://en.wikipedia.org/wiki/Mock_object

sarchertech 3y ago
“You’re holding it wrong” was a response from Steve Jobs blaming users for a design flaw. >Mocks are not an Elixir invention I have no problem with Mocks, I have a problem with Mox. Mox is the kludge, not Mocks in general.

goosejuice 3y ago

> You’re also never going to convince me Such confidence, how do you approach testing your clients? Personally I have never used Mox, but I read the originating blog post when it came out and have followed it's principles ever since.

sarchertech 3y ago
By either using Bypass, passing in fake adapters to Req, or injecting a dispatch layer at test time with Mimic. I’ve been doing this for 20 years, you’re definitely never going to convince me that an interface for a single implementation is the best way to create the dynamic dispatch you need for testing.
- goosejuice 3y ago
  Bypass is a nice alternative if the client is what's under test. Often it's not. > passing in fake adapters to Req, or injecting a dispatch layer at test time with Mimic. I see, so you buy into DI for the purposes of testing but you prefer a more terse approach than what behaviours offer. The extra module never really bothered me and the contents are mostly what would go into the implementation anyway. LSP provides documentation all the same. > I’ve been doing this for 20 years, you’re definitely never going to convince me I certainly appreciate your input, I like to learn new things, but have little interest in trying to convince anyone that makes such a dogmatic statement. An unfortunate thing to hear from a principle developer. I hope your coworkers agree with you.

thibaut_barrere 3y ago

> Mox is nothing more than a kludge to get around the limitations of the language and I think there are much less invasive kludges available. To be honest when I’m working with devs who are new to elixir I’m embarrassed when I have to explain how Mox works. There are other ways, more similar to Ruby etc (e.g. https://github.com/edgurgel/mimic https://github.com/edgurgel/mimic, or with_mock etc). And also there is the risk to "over-mock", for sure. But a good middle ground brings the right value here!

sarchertech 3y ago
I’ve used mimic an I think it’s a much better option than Mox.
- sph 3y ago
  We spoke about this topic for far too long today, but looking at Mimic and its "nothing is mocked unless I tell you to" design, it works only iff you are using mocks the wrong way and at the wrong boundaries.
  - sarchertech 3y ago
    There’s no reason you can’t setup your tests so that mimic stubs out your module or a subset of functions in your module everywhere where you don’t explicitly override it. The main difference is that the extra dispatch layer is only injected at test time, so there’s no extra indirection in the production code.

throwawaymaths 3y ago

> Mox is nothing more than a kludge to get around the limitations of the language and I think there are much less invasive kludges available. You're definitely using or setting up mox wrong. Mox is incredibly good: it lets you do things in elixir that you definitely can't do in other languages: concurrently running tests with different mocks.

sarchertech 3y ago
You can do that in every language I’ve worked with. You can even do it with Mimic in Elixir without the extra production indirection layer.
- deleted 3y ago
  [deleted]