I don't see anything wrong with adding tests to confirm things. A common case is when someone says "I think that breaks when ...". The ideal response, in my view, is just to add the test and run them. Let the computer decide.
As for adding tests in case of refactoring, that seems speculative to me and therefore probably wasteful. In an interview situation, of course, it's a question of how badly one wants the job offer.?
But there's nothing wrong with writing an additional test in response to a concern or question or doubt.
R
I had a live coding interview yesterday and I faced interesting ( at least for me) issue.?
A small background: I was about to implement a function ?to figure out if sum of any 2 elements in input array is equal to given number. Example?
Input. ? ? ? ? ? ? ? Output?
[1,2] and 3 ? ? true?
[1,2,3] and 5 ? ? ? true?
[1,2,3] and 4 ? ? ? ? true?
[1,2,3] and 6 ? ? ? ?False?
As I was constrainted by time (~ 25 mins) I started with TDD but decided to skip most of micro steps.? In the end I implemented something pretty naive ( with O(n^2) complexity - comparing sum of all possible pairs) but it wasn’t highly welcome by interviewer.?
Moreover my interviewer wanted ?me to add extra test cases ?( beside the ones which brought me to my solution - as shown above ) just in case when” in future you want to refactor an existing solution to something more sophisticated”. I strongly refused as these tests will not make any sense from TDD point of view: they will all immediately pass.?
Do you believe that adding extra tests cases “for future refactoring” makes sense ??
I can imagine that for a particular solution of this task ( algorithm being sorting input list + using 2 pointers) If I go strictly with TDD ( a new test case must first fail) a new solution would ( but does t need to ) require a different test cases...
What do you think ?
Is it possible that TDD is not a good fit for strong “algorithmic tasks” ?
Ron Jeffries
It was important to me that we accumulate the learnings about the application over time by modifying the program to look as if we had known what we were doing all along.
-- Ward Cunningham
