4 ms·
> An even bigger issue I have is the huge reliance on mocking which leads to completely brittle tests and code that can withstand no change without all hell bre
by u801e 8y ago
> An even bigger issue I have is the huge reliance on mocking which leads to completely brittle tests and code that can withstand no change without all hell breaking lose.
In my opinion, unit tests should only cover code that doesn't have any side-effects or interact with external dependencies. For example, suppose you have a method that handles a HTTP request, extracts information from that request, create a database query, query the database, processes the results from the DB, generates a HTTP response, and then sends the response back to the client. You can easily factor out the parts that don't have external dependencies into their own methods. For example, you could pass in a HTTP request as a parameter to the method that extracts information from it and then returns that information.
If you unit test those methods, then you would have coverage for everything other than the actual interaction between the HTTP server and client and the interaction between the server and database. Those cases can then be covered with integration tests where an environment is set up that runs test instances of the HTTP client, server, and database.
- monocularvision 8y ago> In my opinion, unit tests should only cover code that doesn't have any side-effects or interact with external dependencies. Almost sounds like functional code is the easiest to test code...
- flukus 8y agoI'd say procedural more than functional, it drives you to avoid encapsulated state and that's about it, unless of course you want to define C's level of abstraction as functional :)
- canhascodez 8y agoI 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?