to promise or not to promise

[johlrogge]

@cjohansen @augustl (I cc you guys here because this is a discussion that can benefit from some input from those who know busters internals well and has some sense of the direction buster will go and may quite possibly have debated this very design question before. Also, I'm not sure if you're watching this repo :) ).

To be able to compose asserts it would be convenient if all asserts would return a promise that is either:

• rejected indicates a failure
• resolved [with the actual] indicates a success

The problem is that as soon as you enter the land of promises you're sort of stuck there and can't for instance throw an exception for failure (especially if you're nesting asserts) please correct me if I'm wrong

That would, as it is today require users to return their asserts (or promise chains that contain asserts).

The obvious downside is that you would have to run the tests asynchronously... In theory you could keep track of deferred asserts and wait for all of them to be rejected, resolved or rejected with a timeout. The more I think about that can of worms though makes it seem like it's not reliable enough and it would be too easy to make mistakes that lead to asserts not being registered before the test has exited...

Tossing this one up for debate while I'm thinking about something better

[johlrogge]

The easy way forward would be to update defineAssertion in referee so that it simply returns truthy for success and falsey (and optionally exception) for failure. Perhaps undefined for success and the message for failure???

[meisl]

Nothing substantial from my side, just a thought:

[...] as soon as you enter the land of promises you're sort of stuck there [...]

a "Promise" monad, one-way like the "IO" monad?

[johlrogge]

I'm not familiar enough with the IO monad to answer that one :(. After debating a larger issue with myself for a few days I am leaning towards using promises and hence not supporting failure detection via exceptions. I will open a new issue to explain why I feel this is necessary and what tradeoffs I think we are making and why I think that the benefits outweigh the costs.

[meisl]

I'm not familiar enough with the IO monad to answer that one :(

Really just a thought, still trying myself to fully understand monads :}