I'm glad you got some new ideas for your teams. I guess the life of actors and stunt performers is precarious. Hopefully less of a problem for developers using Test Doubles!
I’ve always found mocking libraries make tests hard to read and understand. I assume that that creating your own spies and what not is more verbose, but easier to read in tests because you have control over method names to giving better semantics rather than interpreting the semantics from generic functionality.
I don't know if you saw the session briefing towards the end of the video - I show some code using a mocking library and it does seem to me to be harder to read and understand, but it is less code overall than the code I wrote in the demo.
@@EmilyBache-tech-coachit may be more code when comparing a single test, however, the spy can be reused unchanged across many tests. I’m pretty sure the Mock would need to be explicitly set up for each test. Perhaps the setup of the Mock could be extracted into a function, but I’m sure there would need to be more customisation per test, meaning more setup methods. It would get confusing quickly. There are two other benefits to the spy approach: there is no magic… you can run the debugger and step through the code in the Spy to see what is happening. The test using the spy is just testing, whereas, the test with the Mock is managing the mock and testing. I feel there is less to think about with the Spy. Thanks again for your vid! I shared one of them with my colleagues this morning. I hope you got a few more likes and subscribes.
@@EmilyBache-tech-coach another drawback to mocking libraries I’ve been tackling with today is how intimately they are coupled to my implementation under test. My test stopped working because of a refactor. It turns out the method being mocked needed to change, so my functionality wasn’t getting the values my test expected. It’s very brittle. Had we been using spies and the like, they would have been refactored along with my implementation. It’s frustrating because I’m new to this codebase, I only wanted to make a little change, and that change is now growing in scope. It took me a long time to work out the rationale behind all the mocking and how it all fit together.
I want to say that, at the end of Supergirl, Faye was...done away with. :)
Thank you for this video. I have lots of ideas I could adopt for my teams.
I'm glad you got some new ideas for your teams. I guess the life of actors and stunt performers is precarious. Hopefully less of a problem for developers using Test Doubles!
I’ve always found mocking libraries make tests hard to read and understand. I assume that that creating your own spies and what not is more verbose, but easier to read in tests because you have control over method names to giving better semantics rather than interpreting the semantics from generic functionality.
I don't know if you saw the session briefing towards the end of the video - I show some code using a mocking library and it does seem to me to be harder to read and understand, but it is less code overall than the code I wrote in the demo.
@@EmilyBache-tech-coachit may be more code when comparing a single test, however, the spy can be reused unchanged across many tests. I’m pretty sure the Mock would need to be explicitly set up for each test. Perhaps the setup of the Mock could be extracted into a function, but I’m sure there would need to be more customisation per test, meaning more setup methods. It would get confusing quickly. There are two other benefits to the spy approach: there is no magic… you can run the debugger and step through the code in the Spy to see what is happening. The test using the spy is just testing, whereas, the test with the Mock is managing the mock and testing. I feel there is less to think about with the Spy. Thanks again for your vid! I shared one of them with my colleagues this morning. I hope you got a few more likes and subscribes.
You make some good point there, thanks. I hope your colleagues like my videos too!
@@EmilyBache-tech-coach another drawback to mocking libraries I’ve been tackling with today is how intimately they are coupled to my implementation under test. My test stopped working because of a refactor. It turns out the method being mocked needed to change, so my functionality wasn’t getting the values my test expected. It’s very brittle. Had we been using spies and the like, they would have been refactored along with my implementation. It’s frustrating because I’m new to this codebase, I only wanted to make a little change, and that change is now growing in scope. It took me a long time to work out the rationale behind all the mocking and how it all fit together.