6 ms·

Personally, I hate promises, but on topic > write unit tests for your code without mocking, by specifying the expected content, results, and order of side-effe

by krisdol 11y ago

Personally, I hate promises, but on topic > write unit tests for your code without mocking, by specifying the expected content, results, and order of side-effects performed by a function No mocking? This is absurd. Some functions rightfully hit databases and the network. It either gets tested the right way, with mocks; the wrong way, with actual network calls; or not at all, as the author seems to suggest. Mocking belongs in some part in unit tests

tel 11y ago
The idea here is that you can separate your "functionality basis" which does require mocking because it genuinely hits the database from "composed functionality" which operates through a pure, monadic DSL and eventually calls down to the functionality basis. In practice, that functionality basis can be far tinier than the set of things which would require mocking normally. This is a big win. Also in practice you may want to make the functionality basis larger than it need be semantically because this can be a performance win.
bonobo3000 11y ago
If you can write very pure code, mocking is not needed. For example, a function for a database call could return a closure of what to do given a cursor into the database, or a SQL query which can be tested. The side-effecting functions themselves would just create a connection to a db or network host and do exactly what is prescribed in the request, making them simple enough to not need to unit test. This is one of the big benefits of FP and pure functions really. I'm sure there would be practicalities that get in the way of doing this cleanly for all code, but it can go a surprisingly long way. The idea is to write a completely pure core and restrict input/output to be through a few small and obviously correct functions.
- lkrubner 11y ago
  "return a closure of what to do given a cursor into the database" Some people would insist that the closure is a mock, but otherwise this is correct, using closures in this way does help isolate one's tests.
- ubertaco 11y ago
  So how does one test the closure?
jghn 11y ago
When you call mocks the right way are you actually referring to mocks or are you referring to stubs?

by krisdol 11y ago

tel 11y ago

The idea here is that you can separate your "functionality basis" which does require mocking because it genuinely hits the database from "composed functionality" which operates through a pure, monadic DSL and eventually calls down to the functionality basis. In practice, that functionality basis can be far tinier than the set of things which would require mocking normally. This is a big win. Also in practice you may want to make the functionality basis larger than it need be semantically because this can be a performance win.

bonobo3000 11y ago

If you can write very pure code, mocking is not needed. For example, a function for a database call could return a closure of what to do given a cursor into the database, or a SQL query which can be tested. The side-effecting functions themselves would just create a connection to a db or network host and do exactly what is prescribed in the request, making them simple enough to not need to unit test. This is one of the big benefits of FP and pure functions really. I'm sure there would be practicalities that get in the way of doing this cleanly for all code, but it can go a surprisingly long way. The idea is to write a completely pure core and restrict input/output to be through a few small and obviously correct functions.

lkrubner 11y ago
"return a closure of what to do given a cursor into the database" Some people would insist that the closure is a mock, but otherwise this is correct, using closures in this way does help isolate one's tests.
ubertaco 11y ago
So how does one test the closure?

jghn 11y ago

When you call mocks the right way are you actually referring to mocks or are you referring to stubs?