Rspec why stub

All we have to do is slightly change our assertions:. Then we Act , calling investigate twice. Finally in the Assert phase we assert that that message was received only once.

The main difference is in the type of assertions that we made, rather than the tool we used. To me, stubbing, mocking and spying are techniques rather than tools. When we wanted to verify a property of the return value of a method, we used stubbing to provide a consistent value to our test subject, so we could make a clear assertion about the value it returns.

When we wanted to verify a property of the communication between two objects, we used mocking to make assertions about the messages our test double received.

Finally, when we wanted to verify the same communication property as before, but make our assertions at the end of the test, we used spying.

These have been contrived examples, but hopefully they illustrate the point: the appropriate technique for one test may not be ideal for another. Category: FutureLearn Local , Learning. Category: Current Issues , General. Category: Digital Skills , Learning , What is.

We offer a diverse selection of courses from leading universities and cultural institutions from around the world. These are delivered one step at a time, and are accessible on mobile, tablet and desktop, so you can fit learning around your life.

You can unlock new opportunities with unlimited access to hundreds of online short courses for a year by subscribing to our Unlimited package. Build your knowledge with top universities and organisations. Learn more about how FutureLearn is transforming access to education. Share this post. Previous post. Next post. Blog categories. At this moment we do care about logic related to adding "processed" string to data. Now we have our validator double, and we should allow it to receive valid?

Let's stub that method:. Now our validator responds to valid? The spec is green. Validator we passed to process method responded true to valid? Let's add another case to check if process method throws an Error for invalid data.

Still, we're not interested in the validator , we just want it to return false for valid? I added the case that checks if it raises Error also I've rearranged cases to contexts for better reading. For that case, we need to stub valid? Ok, we know that it raises an exception for invalid data and we know that it adds "processed" to valid data. The last step to make sure that we actually call validator. Now, we have to set up an expectation for validator to receive valid?

If we want to make sure that object receives any message during execution, we should use mocks. Let's add one more case to make sure that process method is calling validator. For this case, we created our basic object double and then we set an expectation. We expect it to receive valid? That's the main difference between mocks and stubs.

A Test Stub is a fake thing you stick in there to trick your program into working properly under test. One is that it hits the real production API and alters production data. We could comment out the logger.

We can do this by replacing PaymentGateway with a special kind of test double , a stub. This is because our test no longer calls the charge method on an instance of PaymentGateway , it calls the charge method on a test double.

That takes care of the hitting-production problem. What about verifying the logging of the payment? This is a job for a different kind of test double , a mock object or just mock. Now that we have the line that says expect logger. We can verify this by commenting out the logger. We get the following error:. Having said all this, I personally hardly ever use mocks or stubs in Rails.

Instead we write model tests that hit the database and have full access to every single other object in the application. Whether this is good or bad can be debated but one thing seems clear to me: this style of testing eliminates the need for test doubles the vast majority of the time.

The code says logger. Okay, what did we really accomplish? I strongly disagree with the last couple paragraphs, but the top section is extremely valuable.