In my experience, mocking creates tests of implementations, not tests of features. The aim of testing is to verify the expected output is obtained for a given input. Mocking a service defeats this.
There is value in mocking. I understand your point: Don't mock a module that is called by your SUT because in doing so, you couple your test to that implementation of the SUT, rather than having the test simply provide input and assert output. But, if you refactor an element of your SUT, you should update your tests. You should mock various behaviours of this new underlying implementation, so that you can assert the behaviour of your SUT in response. If you refactor, you should write more tests rather than just expect those that exist to pass. You have changed the behaviour of a system, and you should explicitly test how your SUT behaves with the new elements of its implementation in specific states, rather than just presuming everything is okay because tests that were made for an older implementation pass. You have introduced new behaviour. I understand that your focus here is on testing a "feature's" output, and I agree that integration tests are great, but they don't automatically provide better value than tests that use mocks, and, you have to address the fact that if a SUT performs IO, eg calls a DB, you have to manage its state so that your test passes, or, have the test create the state the SUT needs. Managing this can be done and there is value in it, but it doesn't make mocking a bad approach. Mocking allows you to create great coverage, especially in mature projects.
For simple, easier feature tests. I do use command instead of unit test, faster and easier but accurate xD It is more simple and easy to maintain if there is any refactor too. And like you said, it is not mocking case, but real case cover. So confidence improve!
In my 19 years in software development, I’ve rarely felt compelled to debate publicly with developers I deeply respect. However, I must challenge your assertion that mocking should be entirely abandoned. Your view reflects a misunderstanding of its purpose in software development. Mocking is not just a technical tool but a means to simulate and isolate components in complex systems, allowing us to test system boundaries in controlled environments. So, dismissing it undermines its philosophical foundation in managing unpredictability. While mocking can be misused, such cases are exceptions, not the rule. I expected a more balanced argument rather than sweeping generalizations. This video clearly oversimplifies the concept and hence risks to mislead newbies. As stewards of this profession, we have a community-given responsibility to offer balanced perspectives on principles and practices so as to promote understanding of such concepts not confusion.
So, for example, let's say I have a GenerateReportAction, and a GenerateReportController, which calls this GenerateReportAction with some arguments from the request. Now, I want to test the GenerateReportAction in "isolation", so I know it's doing what I expect, without having to call the endpoint from the tests. I create a test suite for the Action itself. Then, for the endpoint (Controller) test, I only test request validation stuff, the response, AND If the Controller is calling the Action with proper arguments (by mocking the Action). This way, I don't "need" to test the Action on the Controller test, because I have already tested it on the Action test suite. Can you explain to me if I'm wrong, or how would you approach this?
I thought a test should be explicit as possible, no? So, if you refactoring an Action, it should failing both in Action and Controller testsuite. With your approach, there's a possibility, when refactoring your Action, it will cause the Action test fails but succeed in Controller test (bcs of mock). You end up changing your mock instead of the actual test, changing your mock means changing your test. (extra effort) That's why doing mock is better to test implementation of an abstraction/interface (Actions are mostly non-abstract), or test 3rd party services/integration/libs. The extra effort isn't worth for a small change in our own code.
@@awecode Ok, I get it. But lets imagine it's a very complex action, which needs some setup (like creating several Factory Models, etc.), and also creates database rows. If you don't mock it on the Controller test, you'd need to make all this setup, only to test the Controller. And, how would you assert that the Controller is calling the Action with the correct inputs? This wouldn't be possible. For that, you'd need to assert that rows were created in the database with expected values (this way, you'd know that the Action was properly called). You could do that, of course, but you kind already tested all these stuff on the Action test suite. And, if you were to call this Action from ANOTHER Controller, you'd need to make those same assertions? (To make sure the "Controller" is calling the Action) My biggest confusion is: shouldn't we test a logic only in ONE place, and on places where it's being called, only ensure it's being called correctly? I know we'd need to refactor the mocked tests if we were to change the API, but I feel like it'd be easier than doing the above, where you'd need to setup everything and also assert everything where you're calling the Action.
In my experience, mocking creates tests of implementations, not tests of features. The aim of testing is to verify the expected output is obtained for a given input. Mocking a service defeats this.
agreeee
There is value in mocking. I understand your point: Don't mock a module that is called by your SUT because in doing so, you couple your test to that implementation of the SUT, rather than having the test simply provide input and assert output. But, if you refactor an element of your SUT, you should update your tests. You should mock various behaviours of this new underlying implementation, so that you can assert the behaviour of your SUT in response. If you refactor, you should write more tests rather than just expect those that exist to pass. You have changed the behaviour of a system, and you should explicitly test how your SUT behaves with the new elements of its implementation in specific states, rather than just presuming everything is okay because tests that were made for an older implementation pass. You have introduced new behaviour. I understand that your focus here is on testing a "feature's" output, and I agree that integration tests are great, but they don't automatically provide better value than tests that use mocks, and, you have to address the fact that if a SUT performs IO, eg calls a DB, you have to manage its state so that your test passes, or, have the test create the state the SUT needs. Managing this can be done and there is value in it, but it doesn't make mocking a bad approach. Mocking allows you to create great coverage, especially in mature projects.
You are a naturally streamer I reckon! Your videos are short and sweet - at the same time very insightful.
thank you so much!
For simple, easier feature tests.
I do use command instead of unit test, faster and easier but accurate xD
It is more simple and easy to maintain if there is any refactor too.
And like you said, it is not mocking case, but real case cover. So confidence improve!
Very useful thank you soo much!!
In my 19 years in software development, I’ve rarely felt compelled to debate publicly with developers I deeply respect. However, I must challenge your assertion that mocking should be entirely abandoned. Your view reflects a misunderstanding of its purpose in software development. Mocking is not just a technical tool but a means to simulate and isolate components in complex systems, allowing us to test system boundaries in controlled environments. So, dismissing it undermines its philosophical foundation in managing unpredictability. While mocking can be misused, such cases are exceptions, not the rule. I expected a more balanced argument rather than sweeping generalizations. This video clearly oversimplifies the concept and hence risks to mislead newbies. As stewards of this profession, we have a community-given responsibility to offer balanced perspectives on principles and practices so as to promote understanding of such concepts not confusion.
Nice!
So, for example, let's say I have a GenerateReportAction, and a GenerateReportController, which calls this GenerateReportAction with some arguments from the request.
Now, I want to test the GenerateReportAction in "isolation", so I know it's doing what I expect, without having to call the endpoint from the tests. I create a test suite for the Action itself.
Then, for the endpoint (Controller) test, I only test request validation stuff, the response, AND If the Controller is calling the Action with proper arguments (by mocking the Action). This way, I don't "need" to test the Action on the Controller test, because I have already tested it on the Action test suite.
Can you explain to me if I'm wrong, or how would you approach this?
I thought a test should be explicit as possible, no? So, if you refactoring an Action, it should failing both in Action and Controller testsuite.
With your approach, there's a possibility, when refactoring your Action, it will cause the Action test fails but succeed in Controller test (bcs of mock). You end up changing your mock instead of the actual test, changing your mock means changing your test. (extra effort)
That's why doing mock is better to test implementation of an abstraction/interface (Actions are mostly non-abstract), or test 3rd party services/integration/libs. The extra effort isn't worth for a small change in our own code.
@@awecode Ok, I get it. But lets imagine it's a very complex action, which needs some setup (like creating several Factory Models, etc.), and also creates database rows. If you don't mock it on the Controller test, you'd need to make all this setup, only to test the Controller. And, how would you assert that the Controller is calling the Action with the correct inputs? This wouldn't be possible. For that, you'd need to assert that rows were created in the database with expected values (this way, you'd know that the Action was properly called).
You could do that, of course, but you kind already tested all these stuff on the Action test suite. And, if you were to call this Action from ANOTHER Controller, you'd need to make those same assertions? (To make sure the "Controller" is calling the Action)
My biggest confusion is: shouldn't we test a logic only in ONE place, and on places where it's being called, only ensure it's being called correctly? I know we'd need to refactor the mocked tests if we were to change the API, but I feel like it'd be easier than doing the above, where you'd need to setup everything and also assert everything where you're calling the Action.
I was surprised that the laravel cashier docs I a actually recommend you let your tests hit the cashier (testing) api