The best way to develop Motoko?

Developers Language Support
1

Given a few standard approaches to writing code:

  • Write code, write test, run test => pass/fail
  • Write code, compile => returns success or errors

Currently using dfx. It seems the feedback loop for writing motoko can be a slightly slow if you follow this approach:

  • Write code, execute dfx build => returns success or errors
  • Deploy or reinstall code to canister
  • Then call the canister’s method

Is there a faster and more iterative approach to writing motoko, quickly compiling and testing? What are some best practices here?

I noticed there was a moc executable/binary sitting in ~/.cache/dfinity/....../moc

2 Likes
2

would like to know this too.

painful to build, re-install and call the method.

1 Like
3

Try vessel for module test.

4

Vessel is really a package manager and won’t quite help with this problem.

There’s a nice template for writing motoko libraries with unit tests here.

But that’s best for the development of libraries that don’t require inter-canister messaging or actors.

That template actually uses the motoko-matchers framework, which can also be used to test Motoko canisters (though I have not tried the canister support myself):

https://kritzcreek.github.io/motoko-matchers/

Another way to speed up working with dfx is to use the more lightweight emulator, not a full replica, but the emulator is still missing some features of the replica (like measuring cycle consumption). You can select the emulator, instead of local replica, using dfx start --emulator (better dfx stop any replica’s before you do this and perhaps even do rm -r -f .dfx in your project folder)

The moc binary you found is the compiler but can also be used as an interpreter. Again, it does not model all features of the platform such a cycle management or state rollback on trap. You can use it to test simple actors and inter-actor messaging though. Your mileage may vary.

5 Likes
5

Check this: