Re: Tests ¡°scoped¡± to implementation
|
Hi Steve,
I understand the sentiment and I agree with you from a production code?perspective, however the interview may be trying to understand if you understand patterns at all, and you're not helping them by refusing to even try.? I mean, in a typical?programming interview we write a bit of code that nobody needs to solve a problem that nobody has, eg fizz buzz.? Just for the sake of showing that I can, I would do it.? I would also add that in real work, I would wait for the time when using a patterns simplifies the code, rather than complicate it.
TDD is a great technique, but does not constitute all of software development.? Just because writing a test that succeeds without writing any additional code may not be a step in TDD does not mean that such tests cannot serve useful software development?purposes.
Where I tend to quarrel with interviewers is that I firmly believe?in not imposing design patterns until?they emerge in the code, which does not tend to happen until there are additional requirements that motivate reuse.? Many interviewers request speculative design patterns that I resist on principle.? It has cost me more than a few jobs.
On Thu, 16 Jan 2020 at 16:57, Russell Gold < russ@...> wrote: =
I'd add the test because it would require reasoning about the specific code to decide whether it would (probably) run.
Suppose we implemented it with a hash table, for example :)
And that's my point. An order or particular?test cases you wanna have depends (or can depend) on your implementation. If you go for a particular?solution, like Hashtable or do sth else it can simply drive you to write a new test case which shall fail first. I thought that idea of TDD (at least how it was defined by Uncle Bob) is to add a new failing test that would force you to change implementation of your SUT, and not simply repeat what is already done¡?
That depends; if you have known requirements, it makes sense to add unit tests to confirm the corresponding behavior, even if they pass when you write them, as you might change your implementation later and any requirements you forget to test for now could easily be forgotten. The fact that your current implementation happens to pass those tests doesn¡¯t make them superfluous.
Of course you can as nothing prevents you from doing it. In the simplified case i already provided above, what other cases can you add to express the requirement??
I believe that working in micro steps of TDD would allow (in majority cases) to express all requirements as test cases... and other tests would be simply redundant as they will simply duplicate existing test/tests.? In my case by adding all possible tests - for empty array - array with 1 element - array with 2 elements -? summing #1 with #2, #1 with #3 and #2 with #3 for array with 3 elements? and getting to the solution with double/nested loop i can not see any point of adding more tests for my existing implementation. If my implementation would be more sophisticated than I could probably have more/different test cases but for the existing solution i believe it covers all possible options (i am not talking about property-based testing)
br JM
?
br JM ?
R On Jan 16, 2020, at 7:25 AM, Rene Wiersma via Groups.Io < R.wiersma@...> wrote:
Purely from a TDD point of view it is not necessary to write a test for the last case, as we would not have to add or change any existing code to make it pass. However, in this case I would add the test for completeness sake, and future reference.
Ron Jeffries
The seemingly easy way of learning ¡ª by asking ¡ª is not necessarily the best. When you eventually understand, you will understand fully. ¡ª Dragon ? ?The Line War ? ?(Neal Asher)
|
