3 ms·

Apologies for not getting to read and reply to your full post, but I wanted to quickly respond to the request for an example regarding "I need A to behave like

Apologies for not getting to read and reply to your full post, but I wanted to quickly respond to the request for an example regarding "I need A to behave like X". I don't think the example is too contrived: Let's say A is a REST API service. And you wish to check how your code behaves when a client receives a 5XX response. There might be reliable ways to cause A to reply with such a failure, however, if what you intend to verify is this particular behavior, then simply forcing A to reply with a 5XX through mocking will probably get you there quicker, and have it be decoupled from A's implementation (e.g. the conditions that triggered 5XX no longer apply after a version bump, etc) Edit: I took the time to read the full post :). In broad terms, I agree with you. I think however that the approach to software testing allows a bit more nuance, and the usefulness of any approach must be determined more on a case-by-case. In very broad strokes, they follow the pros-and-cons associated with unit- and integration-tests. Are you interested in testing the behavior as end-to-end, then integration tests will get you there more reliably than any complicated setup of unit tests will ever do. Containerized services for temporary deployments is also a great way to spin up such dependencies. However, unit tests serve a different purpose, which deliberately try to be as decoupled from any dependency as possible, and as cohesive as possible. It then follows that if you zoom in to this software unit, and value it for its decoupled nature, and you wish to test how it behaves given certain conditions, mocking is a better and easier way to go about it.

hardwaresofton 6y ago
> Let's say A is a REST API service. And you wish to check how your code behaves when a client receives a 5XX response. There might be reliable ways to cause A to reply with such a failure, however, if what you intend to verify is this particular behavior, then simply forcing A to reply with a 5XX through mocking will probably get you there quicker, and have it be decoupled from A's implementation (e.g. the conditions that triggered 5XX no longer apply after a version bump, etc) Ahh thank you for clarifying what you meant, I see what you mean now, I was imagining something else in my head that was incorrect -- that case makes absolute sense to mock. > Edit: I took the time to read the full post :). In broad terms, I agree with you. I think however that the approach to software testing allows a bit more nuance, and the usefulness of any approach must be determined more on a case-by-case. In very broad strokes, they follow the pros-and-cons associated with unit- and integration-tests. Are you interested in testing the behavior as end-to-end, then integration tests will get you there more reliably than any complicated setup of unit tests will ever do. Containerized services for temporary deployments is also a great way to spin up such dependencies. However, unit tests serve a different purpose, which deliberately try to be as decoupled from any dependency as possible, and as cohesive as possible. It then follows that if you zoom in to this software unit, and value it for its decoupled nature, and you wish to test how it behaves given certain conditions, mocking is a better and easier way to go about it. Fully agreed here! Case by case is the way to decide when to use either tool, and I think that kind of timing (what level of "zoom" you're at in the codebase) is pretty reasonable as a metric.

hardwaresofton 6y ago

> Let's say A is a REST API service. And you wish to check how your code behaves when a client receives a 5XX response. There might be reliable ways to cause A to reply with such a failure, however, if what you intend to verify is this particular behavior, then simply forcing A to reply with a 5XX through mocking will probably get you there quicker, and have it be decoupled from A's implementation (e.g. the conditions that triggered 5XX no longer apply after a version bump, etc) Ahh thank you for clarifying what you meant, I see what you mean now, I was imagining something else in my head that was incorrect -- that case makes absolute sense to mock. > Edit: I took the time to read the full post :). In broad terms, I agree with you. I think however that the approach to software testing allows a bit more nuance, and the usefulness of any approach must be determined more on a case-by-case. In very broad strokes, they follow the pros-and-cons associated with unit- and integration-tests. Are you interested in testing the behavior as end-to-end, then integration tests will get you there more reliably than any complicated setup of unit tests will ever do. Containerized services for temporary deployments is also a great way to spin up such dependencies. However, unit tests serve a different purpose, which deliberately try to be as decoupled from any dependency as possible, and as cohesive as possible. It then follows that if you zoom in to this software unit, and value it for its decoupled nature, and you wish to test how it behaves given certain conditions, mocking is a better and easier way to go about it. Fully agreed here! Case by case is the way to decide when to use either tool, and I think that kind of timing (what level of "zoom" you're at in the codebase) is pretty reasonable as a metric.