Dealing with traps in motoko unit tests

Mops is making testing a breeze, but I’ve encountered a few gotchas.

How do you all deal with traps? You can’t try/catch them because they are not await functions.

If I want to call something and test that it traps appropriately I’m not sure I can do it in a unit test and will have to move it to an actor test.

1 Like

I don’t really have an answer for directly the issue. but I have found that i try to never use traps unless i absolutely have to, and everything is essentially handle with Result<TOK, TError>. It is a bit more tedious sometimes but overall i have found it really helpful to handle error cases and making it clear that those error cases exist

1 Like

This is the direction I’m heading…I’m building a library that is a Lego brick for an actor and the standard for that actor says that certain things should trap. I think I’ll have the library not trap, but return an error of some kind and then have a returnTool that will wrap each response at the actor level and trap if necessary.

1 Like