开云体育

The interviewer can certainly provide a new requirement to implement and then motivate refactoring to design patterns that unify commonalties in the implementations (or even provide additional code to

Hi Jakub, My two cents: to me, there's a subtle difference between writing tests (to guide the development) and testing (to make sure that are no bugs) [1]. I think it's great that TDD guides you/us

wrote: Surprisingly, no I can’t! I googled but found nothing. It’d be a good topic for an article, if anyone is thinking of something to write about.

Why not let the interviewer be the “additional requirements that motivate reuse”? You can explain your reservations but then go ahead with the new requirements. JD Sent: 16 January 2020 17:31 To:

I suppose that's what one is supposed to do with that example. :) R Ron Jeffries ronjeffries.com <http://ronjeffries.com/> If it is more than you need, it is waste. -- Andy Seidl

Yes ... this is a case where removing duplication in tests would appeal to me more than it usually does. R Ron Jeffries ronjeffries.com <http://ronjeffries.com/> I don't necessarily agree with

@Nat Can you point me to a good example of performing these kind of refactorings. I know what are property-based tests but i have been always consider their usage pretty limited or academic br JM

I don’t know how many tests you really need for a python one-liner like that. `return any((sum(pair)==6) for pair in permutations(list, 2))` Check empty list returns false Check for no matches Check

This is a situation where I’d consider refactoring the example based tests to property-based tests. This would make the intent of the tests more explicit, because the reader does not need to infer

Yes. One needs to be careful not to let the tests be implementation-dependent. That suggests to me that the list of 4 might be too few. Suppose, for example, that we think (rightly or wrongly) that

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

On Thu, 16 Jan 2020 at 16:57, Russell Gold <russ@...> wrote: > = > > On Jan 16, 2020, at 10:43 AM, Jakub Milkiewicz <jmilkiewicz@...> > wrote: > > > > On Thu, 16 Jan 2020 at 13:42,

= That depends; if you have known requirements, it makes sense to add unit tests to confirm the corresponding behavior, even if the

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

If you already have tests: [1,2] and 3 true [1,2,3] and 5 true [1,2,3] and 4 true [1,2,3] and 6 False and working implementation (based on 2 loops to compare each possible pair in the input array)

I don’t understand the idea that they are noise. If they confirm desired behavior, having them seems a plus. So why would you feel a need to remove them?

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 :) R Ron Jeffries

Imagine the following inputs, and expected outputs: (true, true) should return 0 (true, false) should return 1 (false, false) should return 2 (false, true) should return 2 Purely from a TDD point of

Thx Ron. Actually I added more tests as requested by interviewer but at the moment I saw then all passing I deleted them as I consider them as a noise and redundant code ( given I stick to my

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.