The Big TDD Misunderstanding. 💡Rumors have it that the term “unit”… | by Oliver Wolf | Medium

💡Rumors have it that the term “unit” in “unit test” originally referred to the test itself, not to a unit of the system under test. The idea was that the test could be executed as one unit and does not rely on other tests running upfront (see here and here). However, when people consider a “unit” as a class/method of the system, two things usually happen. The primary consequence is that developers dogmatically write one “unit test” for every class or method. The second consequence is the isolation of these “units” from other “units” using test doubles (mocks). Now, you change a little thing in your code base, and the only thing the testing suite tells you is that you will be busy the rest of the day rewriting false positive test cases. The argument for isolating the units from each other is that it is easier to spot a potential bug. The idea is that the test suite will tell you exactly in which class/method/function the problem is. In my opinion, this does not pay out because of the h

💡Rumors have it that the term “unit” in “unit test” originally referred to the test itself, not to a unit of the system under test. The idea was that the test could be executed as one unit and does not rely on other tests running upfront (see here and here). However, when people consider a “unit” as a class/method of the system, two things usually happen. The primary consequence is that developers dogmatically write one “unit test” for every class or method. The second consequence is the isolation of these “units” from other “units” using test doubles (mocks). Now, you change a little thing i