The following was a sleep induced dialogue about using mocks in testing and that running tests against each function in isolation,even if it uses actual live code in its dependencies.
Q: Why isn't that unit testing?
A: Because Unit Testing when you test one function and only that function.
Q: Isn't that just semantics and an argument used by testing snobs? Who cares as long as the test is seeing if the code works?
A: That might work for simple functions but as soon as your code touches another function you are then testing two functions. So if the code breaks, which function is broken?
Q: You run the tests for the other function. It's like bricks, you build and test the code on the "bottom" of the dependency chain and then work your way up.
A: Do you have a map of all your code and what depends on what at all times? How do you know in what order to run your tests?
Q: Well, once the bottom layer is done, it shouldn't change.
A: Ah, so you never refactor any code once it's written? How do you know if you broke something?
Q: You run the tests for the code higher up.
A: So you DO have a map of all of your code and what depends on what and then an automated system that runs your tests in order of dependency so you know if a change you made broke something....Do you have to run your code against a database?
Q: It's a data driven app, of course we do!
A: Against live data?
Q: We have a copy.
A: Do you have a way of making different permutations of the data you're testing against?
Q: We edit the records in the database or find different accounts that represent what we want to test?
A: So in order to avoid mocking, you've created a system which tracks all dependencies in your app in real time and runs your tests in order of dependency up the chain while keeping a copy of your client database open and editing records so when, you log in through an interface which may or may not exist yet, it gives a different result and then changes the data back quickly before anyone notices and has indexed every possible scenario that will come up and that will run quickly when you have an automated build system?
Q: Why isn't that unit testing?
A: Because Unit Testing when you test one function and only that function.
Q: Isn't that just semantics and an argument used by testing snobs? Who cares as long as the test is seeing if the code works?
A: That might work for simple functions but as soon as your code touches another function you are then testing two functions. So if the code breaks, which function is broken?
Q: You run the tests for the other function. It's like bricks, you build and test the code on the "bottom" of the dependency chain and then work your way up.
A: Do you have a map of all your code and what depends on what at all times? How do you know in what order to run your tests?
Q: Well, once the bottom layer is done, it shouldn't change.
A: Ah, so you never refactor any code once it's written? How do you know if you broke something?
Q: You run the tests for the code higher up.
A: So you DO have a map of all of your code and what depends on what and then an automated system that runs your tests in order of dependency so you know if a change you made broke something....Do you have to run your code against a database?
Q: It's a data driven app, of course we do!
A: Against live data?
Q: We have a copy.
A: Do you have a way of making different permutations of the data you're testing against?
Q: We edit the records in the database or find different accounts that represent what we want to test?
A: So in order to avoid mocking, you've created a system which tracks all dependencies in your app in real time and runs your tests in order of dependency up the chain while keeping a copy of your client database open and editing records so when, you log in through an interface which may or may not exist yet, it gives a different result and then changes the data back quickly before anyone notices and has indexed every possible scenario that will come up and that will run quickly when you have an automated build system?
Comments
Post a Comment