3 ms·

Tests are literally where our requirements live. To not have automated tests would be to not have well-defined requirements.

P5fRxh5kUvp2th 4y ago
cogman10 4y ago
To have automated tests does not mean you have well-defined requirements. I 100% agree with capturing requirements in tests. However, I argue that TDD does not cause that to happen. I'd even make a stronger statement. Automated tests that don't capture a requirement should be deleted. Those sorts of tests only serve to hinder future refactoring. A good test for a sort method is one that verifies data is sorted at the end of it. A bad test for a sort method is one that checks to see what order elements are visited in the sorting process. I have seen a lot of the "element order visit" style tests but not a whole lot of "did this method sort the data" style tests.
- BurningFrog 4y ago
  As a semi-avid TDD:er I agree about what's a good test. I don't see the connection between TDD and your bad tests examples though. I would test a sort method just the way you describe, using TDD.
  - cogman10 4y ago
    Imagine that in the process of implementing the sort method, you decide "I'm going to use a heap sort". So, you say "Ok, I'll need a `heapify` method and a `siftDown` methods, so I'm going to write the tests to make sure both of those are working properly". But remember, we started this discussion saying "we need a sort method". So now, if you decide "You know what, heapsort is garbage, let's do tim sort instead!" Now, all the sudden you've got a bunch of useless tests. In the best case, you can simply delete those tests, but often devs often get intimidated deleting such tests "What if something else needs the `heapify` method"? And that's exactly the problem I was pointing out with the example. We started the convo saying "tests couple implementation" and that's what's happened here. Our tests are making it seem like heap sort is the implementation we should use when we started this convo, we just needed a sorting method. But now imagine we are talking about something way more complicated and/or less well known than a sorting algorithm. Now, it becomes a lot harder to sift out which tests are for implementation things and which are for requirements things. Without deleting the "these tests make sure I did a good implementation" future maintainers of the code are left to guess on what's a requirement and what's an implementation detail.
    - MockObject 4y ago
      You don't write unit tests for heap sort, you write them for sort. Then you get them to pass using heap sort. Later, you replace heap sort with tim sort, and you can write it quickly and with confidence, because the test suite shows you when you've succeeded.
    - BurningFrog 4y ago
      This is very strange and/or confused. All sort methods can and should be tested with the same tests, that assert that unsorted input is converted to sorted output. Choosing heapsort for performance reasons should normally not affect your test suite at all.

P5fRxh5kUvp2th 4y ago

cogman10 4y ago

To have automated tests does not mean you have well-defined requirements. I 100% agree with capturing requirements in tests. However, I argue that TDD does not cause that to happen. I'd even make a stronger statement. Automated tests that don't capture a requirement should be deleted. Those sorts of tests only serve to hinder future refactoring. A good test for a sort method is one that verifies data is sorted at the end of it. A bad test for a sort method is one that checks to see what order elements are visited in the sorting process. I have seen a lot of the "element order visit" style tests but not a whole lot of "did this method sort the data" style tests.

BurningFrog 4y ago
As a semi-avid TDD:er I agree about what's a good test. I don't see the connection between TDD and your bad tests examples though. I would test a sort method just the way you describe, using TDD.
- cogman10 4y ago
  Imagine that in the process of implementing the sort method, you decide "I'm going to use a heap sort". So, you say "Ok, I'll need a `heapify` method and a `siftDown` methods, so I'm going to write the tests to make sure both of those are working properly". But remember, we started this discussion saying "we need a sort method". So now, if you decide "You know what, heapsort is garbage, let's do tim sort instead!" Now, all the sudden you've got a bunch of useless tests. In the best case, you can simply delete those tests, but often devs often get intimidated deleting such tests "What if something else needs the `heapify` method"? And that's exactly the problem I was pointing out with the example. We started the convo saying "tests couple implementation" and that's what's happened here. Our tests are making it seem like heap sort is the implementation we should use when we started this convo, we just needed a sorting method. But now imagine we are talking about something way more complicated and/or less well known than a sorting algorithm. Now, it becomes a lot harder to sift out which tests are for implementation things and which are for requirements things. Without deleting the "these tests make sure I did a good implementation" future maintainers of the code are left to guess on what's a requirement and what's an implementation detail.
  - MockObject 4y ago
    You don't write unit tests for heap sort, you write them for sort. Then you get them to pass using heap sort. Later, you replace heap sort with tim sort, and you can write it quickly and with confidence, because the test suite shows you when you've succeeded.
  - BurningFrog 4y ago
    This is very strange and/or confused. All sort methods can and should be tested with the same tests, that assert that unsorted input is converted to sorted output. Choosing heapsort for performance reasons should normally not affect your test suite at all.