5 ms·

Unpopular opinion, but I always say that unit tests are contracts for the API. If you don't want / don't need to make contract, don't do unit tests. Unit tests

Unpopular opinion, but I always say that unit tests are contracts for the API. If you don't want / don't need to make contract, don't do unit tests. Unit tests main purpose is not to improve code or reduce bug, it's main purpose is to verify the code to work against the contract that's defined in unit tests. Code improvement or bug reduction are added benefit, if any.

dartos 2y ago
> Unpopular opinion, but I always say that unit tests are contracts for the API You’re talking about integration tests or e2e tests. Those don’t sound like unit tests.
- thfuran 2y ago
  Your units don't have some interface through which they interact with other units?
  - bobthepanda 2y ago
    API is accesible public interface, I feel like I’ve seen it used to talk about accessible “to the public/other teams” from a service standpoint but not to describe any sundry public methods of a file.
    - thfuran 2y ago
      No, it's application programming interface.
- matt_j 2y ago
  API doesn't imply integration. Consider any module or package to have an API exposed to the user of the package. Unit tests should assert that the package behaves as expected.
  - bluGill 2y ago
    By users I assume you mean other developers who use the API (including you next week). It would be better to use a different term as often user means "end user" or "customer" and not internal users.
    - matt_j 2y ago
      Yeah, I'm not sure what the better word is. As a programmer, I use APIs. "interact with", "code to/against". I think "user" is OK. We're all users at different levels of abstraction.
- randomdata 2y ago
  That's exactly what Beck described when he originally coined the term.
- bluGill 2y ago
  Unit tests testing the API - if there is no API there then the level of unit it probably too low. The purposes of all tests is to say "No matter what this will never change" - while never is a bit to strong as you are allowed to make changes any API that your unit tests covers will be painful to change, both because the tests will also have to change and so you have nothing to guide you, and also because odds are you don't have good coverage from other tests (integration tests would catch issues, but you rarely have all cases covered). Or to put it a different way, your unit tests should cover units that have a good boundary to the rest of the system. This should sound like a module, but there is reason to have module as a larger thing than your unit (most of the time there shouldn't be, but once in a while this is useful), and so while there is overlap it is often useful to consider them different. Integration tests cover the API, but they do not test the API (well they often use some API as well, but the won't cover all your internal APIs.)

dartos 2y ago

> Unpopular opinion, but I always say that unit tests are contracts for the API You’re talking about integration tests or e2e tests. Those don’t sound like unit tests.

thfuran 2y ago
Your units don't have some interface through which they interact with other units?
- bobthepanda 2y ago
  API is accesible public interface, I feel like I’ve seen it used to talk about accessible “to the public/other teams” from a service standpoint but not to describe any sundry public methods of a file.
  - thfuran 2y ago
    No, it's application programming interface.
matt_j 2y ago
API doesn't imply integration. Consider any module or package to have an API exposed to the user of the package. Unit tests should assert that the package behaves as expected.
- bluGill 2y ago
  By users I assume you mean other developers who use the API (including you next week). It would be better to use a different term as often user means "end user" or "customer" and not internal users.
  - matt_j 2y ago
    Yeah, I'm not sure what the better word is. As a programmer, I use APIs. "interact with", "code to/against". I think "user" is OK. We're all users at different levels of abstraction.
randomdata 2y ago
That's exactly what Beck described when he originally coined the term.
bluGill 2y ago
Unit tests testing the API - if there is no API there then the level of unit it probably too low. The purposes of all tests is to say "No matter what this will never change" - while never is a bit to strong as you are allowed to make changes any API that your unit tests covers will be painful to change, both because the tests will also have to change and so you have nothing to guide you, and also because odds are you don't have good coverage from other tests (integration tests would catch issues, but you rarely have all cases covered). Or to put it a different way, your unit tests should cover units that have a good boundary to the rest of the system. This should sound like a module, but there is reason to have module as a larger thing than your unit (most of the time there shouldn't be, but once in a while this is useful), and so while there is overlap it is often useful to consider them different. Integration tests cover the API, but they do not test the API (well they often use some API as well, but the won't cover all your internal APIs.)