this is a semantic argument that i don’t want to put too much weight into, but i tend to agree that if you need a database instance or an intricate mock you’re not really doing unit testing. what we’re talking about at that point is something closer on the spectrum to an integration test or else the function needs a better scope for its inputs. i mean, “a component that interacts with an external service” has a word defined for it: integration.
Integration refers to “a component that interacting with another component within your project.” "a component that interacts with an external service” just means it is using a dependency, testing it ts still unit testing. And you should not mock third party dependencies.
right it’s a semantic argument and all this stuff is made up, but i’m specifically irked by some testing strategies that i’ve come across personally. big mocks and external dependencies are setup to test something simple in the business logic. it’s not always necessary to setup all that infrastructure to prove the correctness of a unit of code; that part should be abstracted away because it’s not necessarily relevant to the logic under test. the way the data is accessed, the authentication mechanisms, the overall schema—the integration points, if you will—are not necessary for unit testing. i would prefer, instead of broadening the meaning of what a unit test is, to scope the code into smaller more testable units that end up giving a better, more flexible design in the long run.
all that said, i really like this project and use something similar for testing, regardless of what kind of testing you want to call it.
Not only that, but the definition of what is external is relative; I mentioned Redis as an external dependency, but it might be considered part of your service if the module you’re testing is the only producer and consumer of that component.
Similarly, you might have a caching abstraction in the middle that is written and maintained by you/your team. Or any arbitrary number of abstractions that slowly creep outwards your service/module.
This unit vs integration naming / dispute is not helpful at all.
this is a semantic argument that i don’t want to put too much weight into, but i tend to agree that if you need a database instance or an intricate mock you’re not really doing unit testing. what we’re talking about at that point is something closer on the spectrum to an integration test or else the function needs a better scope for its inputs. i mean, “a component that interacts with an external service” has a word defined for it: integration.
Yes, it’s semantics and often an unproductive argument.
Hence the reason I avoid these names on a daily basis and - in this context - would simply refer to them as “tests”.
Integration refers to “a component that interacting with another component within your project.” "a component that interacts with an external service” just means it is using a dependency, testing it ts still unit testing. And you should not mock third party dependencies.
right it’s a semantic argument and all this stuff is made up, but i’m specifically irked by some testing strategies that i’ve come across personally. big mocks and external dependencies are setup to test something simple in the business logic. it’s not always necessary to setup all that infrastructure to prove the correctness of a unit of code; that part should be abstracted away because it’s not necessarily relevant to the logic under test. the way the data is accessed, the authentication mechanisms, the overall schema—the integration points, if you will—are not necessary for unit testing. i would prefer, instead of broadening the meaning of what a unit test is, to scope the code into smaller more testable units that end up giving a better, more flexible design in the long run.
all that said, i really like this project and use something similar for testing, regardless of what kind of testing you want to call it.
Not only that, but the definition of what is external is relative; I mentioned Redis as an external dependency, but it might be considered part of your service if the module you’re testing is the only producer and consumer of that component.
Similarly, you might have a caching abstraction in the middle that is written and maintained by you/your team. Or any arbitrary number of abstractions that slowly creep outwards your service/module.
This unit vs integration naming / dispute is not helpful at all.