Testing "seam" in Elixir

I wonder if it’s possible to mimic a simple “class reopening”/inhertinace-based SEAM in Elixir to alter a module’s behaviour without editing its code.

Here is an example in pseudo-Ruby



class PriceCalculator 

   def calculate_price(order)
     base_price = calculate_base_price(order)
     shipping = calculate_shipping(order)

     base_price + shipping
   end


  def calculate_shipping(order)
     ShippingServices.calculate_shipping(order)
  end
end

Now the calculate_shipping is enabling point to override the shipping costs calculation behaviour because we can override it in tests without altering the production code.

class Test

class PriceCalculatorStub < Price calculator
  def calculate_shipping(order)
     1000
  end
end


 def test_order_price_is_base_price_plus_shipping_price
     assert 1100 == PriceCalculatorStub.new.calculate_price(...)
  end
end

Example is adapted from Legacy Seam

If my assumptions are correct, your calculate_shipping depends on an external API? If yes, then we universally use mocks for such external calls. There is Mox library that I personally always use and similar ones for doing this.

Alternatively, if the things you want to mock in tests are very limited in their scope, you can inject your functions as parameters and later replace them in your tests:

def calculate_price(order, shipping_cost_fn \\ &calculate_shipping/1) do
  shipping_cost = shipping_cost_fn.(order)
  ...
end

There’s two parts here. There’s introducing the interface of the seam and there’s how to switch out the implementation.

For the first one the answer is quite simple. Extract to a function, make the function inputs and outputs the interface. We commonly use Behaviours for that stuff given things usually don’t just need a single callback.

The latter is dependency injection in whatever form you want to do it. Personally I like explicitly passing in dependencies (e.g. GenServer.start_link(Dependency, …) is just that), but you can go with Application.get_env or some other global dependency resolver option. For tests specifically Mox will allow you to use a single behaviour implementing module to inject dynamic code to run.

I’d strongly suggest not getting hung up on the inheritance portion of this. It’s imo irrelevant to what that blog post tries to teach.

I’d also suggest to let loose of the “without altering the production code”. None of the examples of Martin Fowler left the production code untouched.

2 Likes

Both of those methods requires changes in production code. Especially Mox - in terms of pros & cons it’s a totally different technic.

DI with Application.get_env is just too much of a ceremony sometimes. Particularly I consider a behaviour with a single prod implementation that is there just for testing as a lot of ceremony.

The example I have shown doesn’t require any code changes for testing. And whatever Martin Fowler did in the blog post didn’t affect the interface - i.e. no changes to the PriceCalculator clients were needed.

I’d strongly suggest not getting hung up on the inheritance portion of this. It’s imo irrelevant to what that blog post tries to teach.

Agreed. It’s a specific technic that satisfies a number of constraints and the whole purpose of my question is to understand if there is a similar technic that we can use in Elixir codebases. Not a DI through explicitly passing collaborators or making them swappable via application config.

I hope it’s clear what I’m asking.

Imo that kind of thinking is a trap. You by definition now have at least two implementations, not one. It doesn’t matter that only one is used in production.

That’s fair. But I mentioned you don’t need to go the explicitly passing route. You can just as well start some global process somewhere, which provides the dependency to be used. Call that in your code and you don’t need callers of said code to change. Same with Application.get_env. That’s also global state you can read without needing callers to be involved. The big piece here is “global state” no matter the technical implementation. The technical path chosen by Martin Fowler was global state through a static class variable.

2 Likes

Imo that kind of thinking is a trap. You by definition now have two implementations, not one. It doesn’t matter that only one is used in production.

In the case of the method override one of them is not leaking into production. The changes are contained within the test code.
Which I think is a decent scope for a small-scale need.

That’s fair. But I mentioned you don’t need to go the explicitly passing route. You can just as well start some global process somewhere, which provides the dependency to be used. Call that in your code and you don’t need callers of said code to change. Same with Application.get_env . That’s also global state you can read without needing callers to be involved.

That’s what I call a lot of ceremony for a small-scale need. The ergonomics feels off.

The big piece here is “global state” no matter the technical implementation. The technical path chosen by Martin Fowler was global state through a static class variable.

Fair point, but not the one I want to debate. In the example I provided there is no global state.

And I’m specifically interested in the compact and ergonomic solutions. Everything we discussed so far default ways in Elixir, they are well-trodden, I wouldn’t come here to ask/hear about a technique I’ve used a hundred times. That’s boring and a waste of time :\

Yes, because you’re explicitly providing the implementation - through the class name.

The elixir equivalent of that call would be

Shipping.calculate_price(PriceCalculatorStub)

If you consider a hypothetical “before state” of your test it would have looked like this:

assert 1100 == PriceCalculator.new.calculate_price(...)
vs.
assert 1100 == PriceCalculatorStub.new.calculate_price(...)

It would be very useful if you pointed that out. To me the question seemed like someone new coming from the ruby world looking ways on how to do things in elixir. A short sentence including the fact that you are aware of how DI is done in functional languages and mocking tools would save us a lot of time.

Generally speaking if the solutions provided by me and @LostKobrakai are a no-go, then you are out of luck, unless you fancy doing some metaprogramming. I personally cannot see how provided solutions are in any way worse than the one you pointed, but I am not interested in arguing on that as it goes into off-topic.

2 Likes

Yeah, I could have spent a five minutes more to add more context.

I still sense there should be a way to pull off something similar. Maybe with metaprogramming indeed.

To give a concrete example how this could look like in elixir before and after:

defmodule Shipping do
  def calculate_price() do
    call_api() + 15
  end
end

to

defmodule Shipping do
  def calculate_price(calculator \\ nil) do
    calculated = if calculator, do: calculator.calc(), else: calc()
    calculated + 15
  end

  defp calc() do
    call_api()
  end
end
1 Like

Unless you are working alone, I would highly suggest to not go that route. What you think it’s ergonomic and correct, might not fit well with folk coming from other ecosystems, so you will be creating a friction point to just avoid having to write a few lines of code.

1 Like

Of course OOP in Elixir would not work, but there are few things that looks similar and use metaprogramming to achieve similar results:

  1. Kernel.defoverridable/1
  2. oop package (old)
1 Like

You can “patch” the code of a module by decompiling it into Erlang Abstract Format, then do any changes and then recompile the module. You can also namespace it this way.

I implemented it here: punkix/lib/punkix/patcher.ex at master · Zurga/punkix · GitHub

Example usage is here: punkix/lib/mix/tasks/punkix/gen.live.ex at master · Zurga/punkix · GitHub

1 Like

There’s also Efx. It’s a cool library. Personally I found myself going back to Mox, though (not that that matters).

3 Likes

You might want to look at patch, which lets you mock functions without behaviours or DI.

2 Likes

or Mimic

2 Likes

I am mostly using Mimic and I love it, though I believe Efx is amazing but didn’t have the opportunity to use it yet.

1 Like

We encountered some indeterministic failures from patch, the error is about some supervisor stopping or crashing from the package (if I come across again I will update here)

Aside from that, it is very difficult to find the proper interface of a module since there is no behaviour to implement. Sometimes, leading to very messy code and monkey patching way too high instead of closer to where the dependency needs to actually change. Monkey patching randomly just because they can.

Personally, I would avoid patch package and stick to Mox or anything similar that requires to define a behaviour/interface for the dependencies.

1 Like

Thanks for the feedback on the patch @yordisprieto. It would be nice to see the error, indeed.

@Hermanverschooten does Mimic work with private functions?