3 ms·
I would like to believe this, so let's kick it about. I hypothesize that you just get to move state around: that having a pile of perfectly functional code mean
by canhascodez 8y ago
I would like to believe this, so let's kick it about. I hypothesize that you just get to move state around: that having a pile of perfectly functional code means that you then have to setup/inject a lot of stateful stuff in order to actually test anything, and the complexity of the code/testcode system is conserved. Is there a good way to test this? Is the whole system easier or harder to understand if the stateful bits are isolated?
- Retra 8y agoIt depends where your state is. If it's all in one place, set-able in one language, then it's probably no worse. But if your state is spread out across 30 different config files for 12 different versions of software, spread among multiple machines... good luck getting it setup for reproducible tests.
- u801e 8y agoIn the example I gave, the state is held in the outer method. That is, the connections with the HTTP client and the database. The methods that process the data from the request, generate the database query, process the data returned from the database and generate the HTTP response can all be tested by setting up the function parameters and asserting on the return value. Setting up mocks to do things like assert that the function calls another method with a particular set of parameters is not necessary. As for testing interactions with the HTTP client and database, one can set up an environment that runs a actual HTTP client and an actual database server (populating it with test data). Testing against actual implementations is always better than testing against mocks.
- canhascodez 8y agoIt sounds like, "if you wish to make an apple pie from scratch, you must first invent the universe." But, hey, if it's good enough for the universe, who are we to try to improve on that?