2 ms·

Well, I certainly don't end up doing that. There are many ways of doing things, and I guess we do unit tests differently. > When you could just test specified

Well, I certainly don't end up doing that. There are many ways of doing things, and I guess we do unit tests differently. > When you could just test specified and/or observable behaviour of your system, and achieve the exactly same result with fewer tests. In my experience, it turns out to be very difficult to test a specific behaviour 5-10 layers deep from an external interface. Also, when one of those intermediate layers changes, you tend to have to rewrite many of those tests.

troupo 3y ago
> Well, I certainly don't end up doing that. How else are you "unit testing every single function and method"? > it turns out to be very difficult to test a specific behaviour 5-10 layers deep from an external interface. If you don't test it, how do you know your system works for that specific behaviour? Just because you've tested every single function and method in isolation doesn't mean they actually work with each other, or produce the responses the way you need them to. > Also, when one of those intermediate layers changes, you tend to have to rewrite many of those tests. As you should. Otherwise how do you know that your system still works?
- BurningFrog 3y ago
  > How else are you "unit testing every single function and method"? There are many ways to write unit tests, as well as writing code that is easy to test. I don't know how my ways differs from yours, but I don't have much of the problems you mention. > Otherwise how do you know that your system still works? We do have some integration test, of course. But it's a small part of the total test suite.
  - troupo 3y ago
    > I don't know how my ways differs from yours, but I don't have much of the problems you mention. You haven't answered "How else are you "unit testing every single function and method"?" Given a medium-sized project and at least a passing and a failing test case for each function and method, you end up if not with hundreds, but with dozens of tests largely doing the same thing. > We do have some integration test, of course. But it's a small part of the total test suite. So what does your test suite contain? Lots of unit tests for each method and function. What else?
    - BurningFrog 3y ago
      > Given a medium-sized project and at least a passing and a failing test case for each function and method, you end up if not with hundreds, but with dozens of tests largely doing the same thing. I don't understand this comment. If I have one unit test for each function/method, that's just one test doing the same thing.
      - troupo 3y ago
        1. Your unit test probably shouldn't be testing several conditions at once [1] 2. Even if its just one unit test per function/method, even in a medium-sized project it's dozens of tests, many if them overlapping, with no idea if those functions/methods even work together correctly [1] Depends on function/test

troupo 3y ago

> Well, I certainly don't end up doing that. How else are you "unit testing every single function and method"? > it turns out to be very difficult to test a specific behaviour 5-10 layers deep from an external interface. If you don't test it, how do you know your system works for that specific behaviour? Just because you've tested every single function and method in isolation doesn't mean they actually work with each other, or produce the responses the way you need them to. > Also, when one of those intermediate layers changes, you tend to have to rewrite many of those tests. As you should. Otherwise how do you know that your system still works?

BurningFrog 3y ago
> How else are you "unit testing every single function and method"? There are many ways to write unit tests, as well as writing code that is easy to test. I don't know how my ways differs from yours, but I don't have much of the problems you mention. > Otherwise how do you know that your system still works? We do have some integration test, of course. But it's a small part of the total test suite.
- troupo 3y ago
  > I don't know how my ways differs from yours, but I don't have much of the problems you mention. You haven't answered "How else are you "unit testing every single function and method"?" Given a medium-sized project and at least a passing and a failing test case for each function and method, you end up if not with hundreds, but with dozens of tests largely doing the same thing. > We do have some integration test, of course. But it's a small part of the total test suite. So what does your test suite contain? Lots of unit tests for each method and function. What else?
  - BurningFrog 3y ago
    > Given a medium-sized project and at least a passing and a failing test case for each function and method, you end up if not with hundreds, but with dozens of tests largely doing the same thing. I don't understand this comment. If I have one unit test for each function/method, that's just one test doing the same thing.
    - troupo 3y ago
      1. Your unit test probably shouldn't be testing several conditions at once [1] 2. Even if its just one unit test per function/method, even in a medium-sized project it's dozens of tests, many if them overlapping, with no idea if those functions/methods even work together correctly [1] Depends on function/test