Unit tests are indeed better if they use mocks for external activities like database-interaction and interface-calls.

For database-actions, the need is minimal, since everything is rolled back after the unit test has finished as Robert says. And database-actions are very unlikely to cause unexpected results. That being said, it is possible to catch calls to the database and replace them with the response, but I don't know how.

For interface calls, you need to make the unit test talk to a mock server. This can even be implemented in the application itself. To do so, wrap your regular API-call in a microflow that checks if it is running a unit test. This can be done by setting a session variable like IsUnittest. Set that to true in the unit test microflow. Make the API-wrapper, If IsUnittest is true, then replace the url with the url of the mockserver. NB since you don't want the unit test to run in production, you should have the API-wrapper first check if the environment is production.

You could check out the ExecuteMicroflowAsUser Java action from CommunityCommons.

If you are using the Unit Testing module, each test is run in its own transaction. This means any commits, deletes, or changes are all rolled back at the end of each test so your original data is preserved. 

The Unit Testing module also lets your setup and teardown test data before and after your tests run.

Is this what you mean by a mock session?

Hope this helps.