4 ms·

I've never been able to fully grasp mocking and stubbing.

by PLejeck 13y ago

nl 13y ago
Mock = Responding to requests with no (or minimal) handling of logic. In SOA it can be as simple as putting a set of files containing the expected responses (in XML or JSON form) on a webserver and using mod_rewrite to make sure it responds with the correct file to a given request.
tunesmith 13y ago
The most common objection I've heard to mocking is along the lines of, "If you're mocking, what is the point of the test?" The answer lies in having a clear understanding of what you are testing. For instance, method A might call another class's method B. If you're writing a unit test for method A, you don't also want to test method B. (Other unit tests would test B in isolation, instead.) So in A's test, you make A call a mock B rather than the real B, and you ensure B returns a particular kind of response. In other words, you want to make sure method A behaves correctly when it gets certain responses from B. So in english, a test is basically saying, "When B gives this type of response (which I'm forcing it to respond with), make sure A behaves as I expect", and a second test says, "When B gives this other type of response (which I'm forcing it to respond with), make sure A behaves as I expect. So when you write a unit test for A, you mock B by making it send back a canned response and make A use it. Then you call A with some parameters, and then you make sure that A's return type is as you expect. One advantage of this is that if a future code enhancement breaks one of the methods deep in the code, then the failing unit test will tell you exactly where the problem is. Without mocking, a failed unit test will make you have to examine several layers of stack trace to find the bug.
- justincormack 13y ago
  Also getting the right kind of response out of a back end server may be hard, eg getting certain kinds of error or unusual responses, so mocking is the only way to get them reliably. They are not a substitute for end to end tests though, as you cannot tell if some other assumption is broken.

I've never been able to fully grasp mocking and stubbing.

by PLejeck 13y ago

I've never been able to fully grasp mocking and stubbing.

nl 13y ago

Mock = Responding to requests with no (or minimal) handling of logic. In SOA it can be as simple as putting a set of files containing the expected responses (in XML or JSON form) on a webserver and using mod_rewrite to make sure it responds with the correct file to a given request.

tunesmith 13y ago

The most common objection I've heard to mocking is along the lines of, "If you're mocking, what is the point of the test?" The answer lies in having a clear understanding of what you are testing. For instance, method A might call another class's method B. If you're writing a unit test for method A, you don't also want to test method B. (Other unit tests would test B in isolation, instead.) So in A's test, you make A call a mock B rather than the real B, and you ensure B returns a particular kind of response. In other words, you want to make sure method A behaves correctly when it gets certain responses from B. So in english, a test is basically saying, "When B gives this type of response (which I'm forcing it to respond with), make sure A behaves as I expect", and a second test says, "When B gives this other type of response (which I'm forcing it to respond with), make sure A behaves as I expect. So when you write a unit test for A, you mock B by making it send back a canned response and make A use it. Then you call A with some parameters, and then you make sure that A's return type is as you expect. One advantage of this is that if a future code enhancement breaks one of the methods deep in the code, then the failing unit test will tell you exactly where the problem is. Without mocking, a failed unit test will make you have to examine several layers of stack trace to find the bug.

justincormack 13y ago
Also getting the right kind of response out of a back end server may be hard, eg getting certain kinds of error or unusual responses, so mocking is the only way to get them reliably. They are not a substitute for end to end tests though, as you cannot tell if some other assumption is broken.