Hey guys, I’m working on something where I make a call to an external process and it may return a value (of any) or it there’s an error in the external process call then an ErlangError will be raised.
Now since I’ve got no way of knowing what the returned values will be (I mean, I can, but that’s not my module’s responsibility, that’s the external process’) I would like to refute an Erlang Error is raised, or by other words, I want to assert the call is successful, without caring for what is actually being returned.
I can just call the function and then assert true at the end. This way if the test reaches the assertion then it means the call didn’t raise the Erlang Error, but I believe an actual way of refuting an error was raised would be more expressive and a better practice. Is there a way to achieve this?
Hey @NobbZ yeah that’s the conclusion I presented at the end of my post I realize this works, but I just think an actual expression like refute_raise ErlangError, fn -> function end could be beneficial for expressiveness and code maintainability, but I know the way you referenced works just fine!
The test doesn’t sound as useful as it could be, if a function that literally does nothing passes fine. Is it possible to mock / substitute the external process so the return value is predictable? In my app I do this for all external deps, based on José’s classic article.
I agree with dom, and it looks to me that the test belongs in the external process test suite, not yours. In your case, I would invest in integration testing to make sure the state of the whole system plays nicely with the external process.
I realize this works, but I just think an actual expression like 
