3 ms·

If you are writing tests and can switch from iteration to recursion without tests failing, you are missing the point. Code quality is derived primarily through

• adam-a 15y ago
  There are a lot of ideas about what unit tests should be and what they shouldn't be. If the purpose is to ensure my code works with your code and to check that my new changes haven't broken something in another part of the project then the public methods on a class are the right thing to be writing tests for, IMO, and refactoring the private methods or changing from a loop to recursion shouldn't break your tests. If you want to use tests to prove your clever algorithm is giving the right output half-way through then you're right. Certainly I wouldn't call those unit tests though. And that's too low-level if you want to do TDD, where your tests should define the public methods you want to implement. The implementation shouldn't matter so long as the output is what you want.
• daleharvey 15y ago
  Unless you are writing code that is testing the implementation of the loop vs recursion, your tests, unit or otherwise, have absolutely no need to break when you are making changes well below the interface that you are testing at.