5 ms·

This is contrary to most testing tutorials and documentation I've read. I get frustrated and forego a lot of testing because the idea of mocking out basically

This is contrary to most testing tutorials and documentation I've read. I get frustrated and forego a lot of testing because the idea of mocking out basically the whole system in order to unit test is insane to me. If function A calls function B, you've got to mock function B out. If you refactor function B, you better update the mock as well. Writing an app twice hardly seems like a good use of time.

tra3 5y ago
I only mock functionality that is non deterministic — like sending email.
rhdunn 5y ago
That way leads to madness, and I don't follow that style/philosophy of mocking components. Only mock the things you can't easily set up in your unit tests to get them to work, like database connections. For spring-based components, try to use the real components where possible, but where needed use mock components that do enough to get the system working. That does mean that if you are testing function A you are also indirectly testing function B, but that is fine.
pintxo 5y ago
If function A does not much more than calling B, maybe testing A is not strictly necessary. If A does something important/complex/critical/etc maybe the important/complex/critical/etc part can be refactored into a dedicated function A1 without external dependency and then tested on its own? That way, the tests focuses on where the money is and gets easier to work with at the same time.
- adwn 5y ago
  Now you've added an additional, untested point of failure (the glue code), and you've made the interaction between A, A1, and B more difficult to understanding and more error prone.
  - cloogshicer 5y ago
    Exactly, fully agree. I don't understand why people advocate this insane over-abstraction and over-modularization. > more difficult to understanding I think this is the most important one. I hate those code bases where everything is split up into these tiny tiny units and you have no idea what the whole thing does. Reminds me of this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
    - berkes 5y ago
      > you have no idea what the whole thing does But you do have e2e, acceptance or integration tests, don't you? Whenever I see a need to prove, or documentation "how the hole thing does it", that is the moment to write an integration test: isolate "the whole thing" as much as possible, make it as small as possible, then fire some things at it, and see if the outcome works. It's not hard (but not easy either). The hardest point for those tests is to keep the setup and teardown sane.
      - ehutch79 5y ago
        I have absolutely read that the only valid tests are unit tests.
        berkes 5y ago
        And I have absolutely read that evil lizard people invented COVID to inject us with microchips. Doesn't make it true. What I mean with this, is that there'll be many opinions and feelings posed as a fact. About testing too. Which is why I dislike the OP's article, as I pointed out elsewkere in the comments: the things he poses as "rules" (earlier on he calls them tips, which is better imo) aren't rules: they are highly controversial opinions. As would the statement you read be. Daily TDD, is more of an "art" than a science. It requires experience, and fingerspitzengefühl. Though, the science on TDD and BDD is strong and convincing, summarized in "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations"[1]: TDD and BDD significantly helps to build better software. [1] https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339/ref=sr_1_1?keywords=accellerate&qid=1639394831&sr=8-1 https://www.amazon.com/Accelerate-Software-Performing-Techno...
berkes 5y ago
> If function A calls function B, you've got to mock function B out. If you refactor function B, you better update the mock as well This is why isolation and encapsulation are important. Your tests were telling you that A has intricate dependencies on B. If the tests for A start failing when you refactor B, they were (too) tightly coupled. The tests are telling you this (whether or not you act on this is another discussion). And when the tests for A keep passing even when you broke B -false positives- you should see at least one integration (or even e2e) test failing. If not, the tests are showing a hole in the coverage.

tra3 5y ago

I only mock functionality that is non deterministic — like sending email.

rhdunn 5y ago

That way leads to madness, and I don't follow that style/philosophy of mocking components. Only mock the things you can't easily set up in your unit tests to get them to work, like database connections. For spring-based components, try to use the real components where possible, but where needed use mock components that do enough to get the system working. That does mean that if you are testing function A you are also indirectly testing function B, but that is fine.

pintxo 5y ago

If function A does not much more than calling B, maybe testing A is not strictly necessary. If A does something important/complex/critical/etc maybe the important/complex/critical/etc part can be refactored into a dedicated function A1 without external dependency and then tested on its own? That way, the tests focuses on where the money is and gets easier to work with at the same time.

adwn 5y ago
Now you've added an additional, untested point of failure (the glue code), and you've made the interaction between A, A1, and B more difficult to understanding and more error prone.
- cloogshicer 5y ago
  Exactly, fully agree. I don't understand why people advocate this insane over-abstraction and over-modularization. > more difficult to understanding I think this is the most important one. I hate those code bases where everything is split up into these tiny tiny units and you have no idea what the whole thing does. Reminds me of this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
  - berkes 5y ago
    > you have no idea what the whole thing does But you do have e2e, acceptance or integration tests, don't you? Whenever I see a need to prove, or documentation "how the hole thing does it", that is the moment to write an integration test: isolate "the whole thing" as much as possible, make it as small as possible, then fire some things at it, and see if the outcome works. It's not hard (but not easy either). The hardest point for those tests is to keep the setup and teardown sane.
    - ehutch79 5y ago
      I have absolutely read that the only valid tests are unit tests.
      - berkes 5y ago
        And I have absolutely read that evil lizard people invented COVID to inject us with microchips. Doesn't make it true. What I mean with this, is that there'll be many opinions and feelings posed as a fact. About testing too. Which is why I dislike the OP's article, as I pointed out elsewkere in the comments: the things he poses as "rules" (earlier on he calls them tips, which is better imo) aren't rules: they are highly controversial opinions. As would the statement you read be. Daily TDD, is more of an "art" than a science. It requires experience, and fingerspitzengefühl. Though, the science on TDD and BDD is strong and convincing, summarized in "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations"[1]: TDD and BDD significantly helps to build better software. [1] https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339/ref=sr_1_1?keywords=accellerate&qid=1639394831&sr=8-1 https://www.amazon.com/Accelerate-Software-Performing-Techno...

berkes 5y ago

> If function A calls function B, you've got to mock function B out. If you refactor function B, you better update the mock as well This is why isolation and encapsulation are important. Your tests were telling you that A has intricate dependencies on B. If the tests for A start failing when you refactor B, they were (too) tightly coupled. The tests are telling you this (whether or not you act on this is another discussion). And when the tests for A keep passing even when you broke B -false positives- you should see at least one integration (or even e2e) test failing. If not, the tests are showing a hole in the coverage.