Lots of systems separate commands and queries. Commands would be difficult to test without some mocking.

if you're calling a void function then by definition you're calling a function that does nothing but side effects or calling off to other classes. In the latter case, they can be good candidates for refactoring in my experience. A function that does something but doesn't either produce mockable side-effects or return information may be a code smell.

A function can return void and still throw an exception. (Like one I wrote today, "insert row into table", which throws on failure and return nothing on success.)

A bunch of functions that all return void all being called in a row, though? That's a much smellier smell. What happens if their order gets mixed up, for example.

Testing that function would be a matter of mocking out the database with a class that can emulate the type of failure that would trigger your exception.

Ooooh, yes. Testing error-handling code is another thing I keep on forgetting to do.

it's almost more worthwhile than testing your happy path - when things go wrong you want to have guarantees that they'll be handled correctly and not kill your server.