Lol, yeah Google isn’t very good about searching for programming stuff, DuckDuckGo is actually a LOT better for searching for programming related terms, it even has whole search modes for it that Google doesn’t have.

The most basic, direct, and unreadable thing would be from Haskells wiki:
Type witness - HaskellWiki

Even OCaml has an example of them in the GADT section of the official spec: https://caml.inria.fr/pub/docs/manual-ocaml/extn.html#sec256

But in an Elixir world it would be like:

def blah(value, witness), do: witness.(value)

Or in a module form:

def blah(value, witness), do: witness.bloop(value)

In essence a witness is just a type or action that depends on a type.

Typeclasses, like in Haskell, are a non-generic form of witnesses. Like take this function in Haskell:

add :: Num a => a -> a -> a
add l r = l + r

The Num a is a typeclass, if you call this function like add 1 2 it will return 3 and if you call it like add 1.0 2.0 it will return 3.0, for any type that fulfills the typeclass Num 'a. However, look at the =>, that’s just a special operator in Haskell that means to ‘auto-fill what comes before’, let’s turn that back into a ->:

add :: Num a -> a -> a -> a
add w l r = (+) w l r

Now you have to call it like add (Num Int) 1 2 to return 3, that Num Int is the witness, the typeclass is essentially a module reified on that specific type based on the typeclass definition of it, and it passes that module in that location (it’s actually a record in Haskell, but whatever).

In other words, a witness just allows you pass an action over some other type into a function. Haskell’s typeclasses make it “baked in”, in that you can define a witness globally and it can be used globally, but you can’t change it, it is what it is defined as, where if it is something you have to pass in manually, as the OCaml ecosystem does, then you can change it at will, which makes, for example, mocking it absolutely trivial.

Passing in a module or a set of functions into something to operate on a value, whether also passed in or existing entirely internally, but is specified and handled by those functions, makes those functions/module a witness.

In Elixir, I keep my work program very segmented as lots of small dependencies, but they all share the main app’s Repo instead of their own by me defining the MyServer.Repo module in the global config for each dependency, they then access it just via Application.get_env/2 each time they need it (via a default option on function args, but close enough). In other words I am passing in a witness, the Repo, to ‘witness’ or operator over the data that is being processed, I.E. t he schemas and changesets. This is a pattern I use, probably excessively, because of my OCaml history (super common pattern there), and consequently it makes it sooo easy to ‘mock’ things without needing to grab a code generator like Mox or so.

As an addition, I heavily follow the pattern of almost every function taking a set of optional named arguments, like:

def blah_something(a, b, c opts) do
  repo = get_repo(opts)
  # Use stuff like `repo.insert/1`
end

Where get_repo is essentially this defined fairly globally included:

Application.get_env(...) || throw "Repo not set for #{...}"
def get_repo(params, opts \\ []) do
  key = opts[:key] || :repo
  cond do
    is_atom(params[key]) -> params[key] # This actually checks the basic structure of the module
    Application.get_env(...) -> Application.get_env(...)
    # other stuff
    :else ->
      Logger.error "blah"
      raise %NoRepoException{}
  end
end

So I can define a repo globally for a dependency, or I can redefine it on a function-by-function basis, etc… Regardless, it’s just a witness being passed in ‘somehow’ that the functions use to perform work. It’s an exceptionally old pattern in ML languages.

I work on a project that is very much an integration layer between many 3rd party APIs (20-ish including stripe). All of our automated tests go through mocks in some form or fashion. Depending on how “old” a particular integration is we might use the hex package bypass in some cases, but we also have a home-built global mocking framework that prevents async tests and is based upon indirection in the Application.env. Lately we’ve moved to a struct-based command/token approach which I have discussed a bit publicly (GitHub - gvaughn/quest: Pattern for building API clients in Elixir · GitHub).

In any case, we do not have automated tests that actually hit 3rd party APIs. We’re prepared to deal with a temporary production outage if a 3rd party changes their responses significantly. But if that is a high concern of yours, yes, I’d use an ExUnit @tag to manage when it is executed.

There is no silver bullet. I have a very personal take on testing, some people agree others don’t. What I can say in your case, is that you shouldn’t make your application dependent on Stripe, you should have a connector, a contract, and then have the Stripe client implement that contract. At least, this is the original idea Jose Valim has about testing in Elixir: Mocks and explicit contracts « Plataformatec Blog

Thus, I believe the community would suggest something among the lines of:

1. Define a contract
2. Use a mock that obeys the contract in your tests

Me personally, I prefer constructor dependency injection. When I create my entities in Elixir, I simply pass them the set of functions they are going to use (I inject the dependencies). Then when I need to test, I simply pass dummy functions as dependencies, or better, I pass stubs and spies to make sure I am performing the external calls as I am supposed to.

This goes in line with behavioral tessting, some people don’t like it because it couples your test to your implementation a little bit more, but I find this is the best way to ensure every unit works as intended. As usual, YMMV.