Best practices for debugging Motoko?

Hi,

In the rare occasions I have to read or write Motoko, I find it tricky, mainly because of having to deploy, making development iterations slow - probably there are better ways around this, as I found out about Haskell (it’s not a language I have knowledge) to write unit-tests, or the Motoko Playground.

What could help is to find how to use the mo:base/Debug to output any custom types, for example?

Any tips are appreciated,

Thanks!

1 Like

You can use debug_show(...) which turns any value into Text. Then you can use Debug.print(..) to print the text to console. But you need to deploy your canister locally and call the method in order to run it.

For faster iteration, you can invoke the motoko compiler moc directly. For example, $(dfx cache show)/moc should give you the command.

3 Likes

If using the playground, you can also log messages by appending them to a mutable variable of type Text and providing a query to read that variable.

Not great, but not terrible either.

3 Likes

GitHub - kritzcreek/motoko-matchers is pretty good for writing unit-tests of mainly libraries but also canisters (from dfx), but may have bit-rotted by now.

Some of the motoko-base libraries have their tests written with motoko-matchers.

1 Like

Thanks! The moc is extremely useful, using it now from now on :wink:

That’s a great idea, thank you so much for that!