3 ms·
I don't know if I asked my question as clearly as possible. Mocking your DB, the file system, the remote API, etc are all a given when doing tests. My question
by lubonay 10y ago
I don't know if I asked my question as clearly as possible. Mocking your DB, the file system, the remote API, etc are all a given when doing tests. My question was aimed at trying to find out if it's feasible to replace the imperative Presenter/Service/etc patterns with a more functional approach.
What I'd like to see is testing only the returned value of a function, as opposed to calling a void function and checking whether the injected mocks got the proper method invocations, i.e. whether the desired side effects occurred.
- beaconstudios 10y agoif 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.
- cytzol 10y agoA 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.
- beaconstudios 10y agoTesting 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.
- cytzol 10y agoOoooh, yes. Testing error-handling code is another thing I keep on forgetting to do.
- beaconstudios 10y agoit'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.
- UK-AL 10y agoLots of systems separate commands and queries. Commands would be difficult to test without some mocking.