The type 'FSI_0002.Polls.Party' does not match the type 'FSI_0003.Polls.Party'

error FS0001: This expression was expected to have type
    FSI_0019.Polls.Party
but here has type
    FSI_0020.Polls.Party

baka kaba fucked around with this message at 08:19 on Feb 17, 2017

• Why does he insist on using something like dependency injection with environment-specific mocks instead of creating mocks on a per-test basis? Is he just trying to find a "pure" Elixir solution to the problem? Am I crazy for feeling like it's an overly ceremonial approach that is difficult to scale?
  
• I feel like his example might appear unobjectionable because he's chosen a single trivial case (the happy path). It seems like it is useful solely for scenarios where a call to a dependency always returns the same response. How would you use this approach to test that your code responds in the expected way to both the happy path as well as when the mocked external dependency returns one or more errors in different tests?
  
• My instincts tell me to use a mocking library (e.g. mock) to mock out the dependencies of each layer of my code differently for each test to measure responses to all the possible cases of returned values from called dependencies, just like I would in any language I already know. I understand that this potentially comes at a cost in Elixir, like perhaps not being able to run tests in parallel due to global scope pollution. Is there anything else wrong with this approach? Are there any other pitfalls awaiting me if I head down this path? Is the fact that I even want to do this an indication that my code smells?
  

def request(qop, het, mim) do
  %{ :endpoint => url("do/a/thing"), :method => :get, :params => params(qop, het, mim) } end

def execute(%{ :endpoint => endpoint, :method => method, :params => params }, opts) do
  :hackney.request(method, endpoint, [], params, opts)
end

def result({ :ok, 200, _, ref }) do
  ...
end

the talent deficit fucked around with this message at 09:30 on Mar 4, 2017