4 ms·

Yes! This can't be repeated enough IMO > Terminology > The test that hits the endpoint is commonly referred to as an “integration test”, and the other test is

by bedobi 5y ago

Yes! This can't be repeated enough IMO > Terminology > The test that hits the endpoint is commonly referred to as an “integration test”, and the other test is commonly referred to as a “unit test”. > Kent Beck (the originator of test-driven development) defines a unit test as “a test that runs in isolation from other tests”. This is very different from the definition of a unit test as “a test that tests a class/method in isolation from other classes/methods”. The test that hits the endpoint satisfies the original definition. > But it doesn’t really matter if you want to call a given test an “integration” test or a “unit” test. The point is the test fails when something breaks and passes when something is improved. If it does the opposite, it’s not a good test. https://medium.com/expedia-group-tech/test-your-tests-f4e361818720 https://medium.com/expedia-group-tech/test-your-tests-f4e361...

mrjin 5y ago
The sadly fact is that lots of people cannot tell the differences between Unit Tests, Functional Tests and Integration Tests even after in the field for over a decade.
- beebeepka 5y ago
  I welcome you to share your opinion on the matter
  - bckr 5y ago
    I'm going to give it a crack. Caveat that I have not read the TDD scriptures. Unit test: tests a bit of code not much larger than a function, to make sure that the function runs properly and gives the expected outputs. Functional tests: tests some code not much bigger than a module (source file) to make sure it does the right things, from a business logic standpoint. Integration tests: tests some systems not much bigger than one subsystem making an API call to another system, to make sure that the systems can talk to each other properly.
    - Aeolun 5y ago
      And the comes End to end test, which tests the whole thing from top to bottom.
    - CJefferson 5y ago
      My problem with this definition is what "tests a bit of code" means. For example, in a codebase I work on we use a custom sort function, and memory manager. We have tests for both (as you would expect). However, both sorting and allocation are fairly large pieces of code. Does that mean any test of any function which calls sort or allocates memory isn't a unit test, as it's (indirectly) using something much bigger than a single function? But "stubbing" out either sort, or memory allocation, seems stupid (the stub would just have to do the same thing).
      - bckr 5y ago
        That makes sense. My immediate reaction is: 1) focus on business logic: is your code "about" sorting and allocation, or could you treat those as built-ins? 2) It's OK if a function is calling other functions. The point is that it's a business-logic-level unit of functionality, which is smaller than a module or so. Ymmv. Maybe we should read the scriptures.

by bedobi 5y ago

mrjin 5y ago

The sadly fact is that lots of people cannot tell the differences between Unit Tests, Functional Tests and Integration Tests even after in the field for over a decade.

beebeepka 5y ago
I welcome you to share your opinion on the matter
- bckr 5y ago
  I'm going to give it a crack. Caveat that I have not read the TDD scriptures. Unit test: tests a bit of code not much larger than a function, to make sure that the function runs properly and gives the expected outputs. Functional tests: tests some code not much bigger than a module (source file) to make sure it does the right things, from a business logic standpoint. Integration tests: tests some systems not much bigger than one subsystem making an API call to another system, to make sure that the systems can talk to each other properly.
  - Aeolun 5y ago
    And the comes End to end test, which tests the whole thing from top to bottom.
  - CJefferson 5y ago
    My problem with this definition is what "tests a bit of code" means. For example, in a codebase I work on we use a custom sort function, and memory manager. We have tests for both (as you would expect). However, both sorting and allocation are fairly large pieces of code. Does that mean any test of any function which calls sort or allocates memory isn't a unit test, as it's (indirectly) using something much bigger than a single function? But "stubbing" out either sort, or memory allocation, seems stupid (the stub would just have to do the same thing).
    - bckr 5y ago
      That makes sense. My immediate reaction is: 1) focus on business logic: is your code "about" sorting and allocation, or could you treat those as built-ins? 2) It's OK if a function is calling other functions. The point is that it's a business-logic-level unit of functionality, which is smaller than a module or so. Ymmv. Maybe we should read the scriptures.