RouterOS scripting is too "simple" (as in... "not good") for a unit testing framework to be reliably written in it, which in turn means there's no viable way to internally do such tests.
You could use the API to do that, i.e. run scripts to run, then analyze their output, and use assertions and reports within your language of choice, as opposed to generating them with the router. That's the best approach today.
I realize resetting the router state is a big problem with the above (and also why unit testing frameworks aren't a trivial thing to write)... You could create a clean VM, and then clone it before each test session.
Unit Testing should be sort of stateless (to me that would mean only test functions input and output, no procedures).
Even shell scripts have unit testing now, for instance at https://github.com/kward/shunit2/tree/m ... ce/2.1/src
I'm not going to dig into the API yet (I try to keep the # of technologies involved small), but thanks for the tips so far.