6 ms·

TDD makes small and frequent commits the natural way to work: figure out the smallest non-trivial step in the right direction, write a single test, verify that

by l0b0 6y ago

TDD makes small and frequent commits the natural way to work: figure out the smallest non-trivial step in the right direction, write a single test, verify that it (not the entire test suite) fails for the right reason, implement the simplest code which makes the test pass, simplify the implementation while making sure the test passes, commit. This way each code change typically amounts to a single new path through the code which is known to be tested. Asking people to use TDD for a coding test is probably a bit much since it takes a long time to learn the ins and outs, but small commits give a little bit of the advantage and can tell you a lot: Does the candidate know how to break the problem into atomic changes? Do they commit only reachable code? Do they create simple, fast, and orthogonal tests?

bgdam 6y ago
> Asking people to use TDD for a coding test is probably a bit much since it takes a long time to learn the ins and outs, This hits close to home for me, I was very recently rejected at an interview (a 1 hour pair programming session), because my approach to fixing the algorithm was 'not TDD enough'. I think that it's really dumb to expect people to go full on TDD in an interview session, where the purpose would ostensibly be too demonstrate analytical and programming ability. Couple that with the fact that they didn't even tell me that there was going to be an emphasis on TDD, it basically amounted to wasting about 3 days of my time for the entire interview process. It is unfair that companies can unilaterally make such demands on your time, while themselves not spending more than a few hours.
atomicity 6y ago
The problem is that OP is dealing with work where design is the hard problem. They need to do prototyping without considering all of the faults of their programming language, all of the concurrency bugs they could make, and all of the logical errors they could make. TDD falls apart here because TDD helps you write code that does what you think it does. When you don't even know whether it's possible to implement what you want to implement, TDD doesn't help. I think the TDD model of implementation is a lot better than most sloppy dev workflows I've seen, but I agree with OP that small commits don't work out in this case. When you aren't sure whether something is possible, you need to stay less detail-oriented. To do so, you switch from TDD mode to prototyping mode. Personally, I have so little faith in my prototype code that I always rewrite it.
axaxs 6y ago
This sounds awful. In fact, TDD as a whole is awful. I'm a developer, I can make any awful code pass any test I want.
- alpaca128 6y ago
  > I'm a developer, I can make any awful code pass any test I want. How is that statement exclusive to TDD or something that makes TDD unviable? TDD isn't about trying to pass some tests no matter how. It's supposed to make you think through the problem and define the interfaces before writing the actual code, when it's still very easy to rearrange and adapt the structure. So that the end result is not awful in the first place.
  - axaxs 6y ago
    I think it's just a paradigm difference. For me at least, I think better about tests -after- implementation. A short example. Let's say I had to write a hash function. If I were forced to write a test for it up front, I'd probably do something naive like ensuring the result of hashing("abc") was 123. Now I start on my code. Oh, I need to return 123, easy enough. Tests pass, ship it! If I implemented the function first, I'd then think about pitfalls -in- the code. Let's give it weird input. Let's give it empty things. Let's make sure that for 1000 random strings, the hashes are different. Things like that, because those are things I think about when -implementing- the code, and typically not prior. I'm not saying that to be snide, that's really how my brain would work. I understand everyone is different, so I'm only speaking for myself.
- mjfisher 6y ago
  I can go one better, and make any program at all compile by removing code with the annoying wiggly red lines under it. The tools and options we have don't exist in a vacuum; you still need good judgement and practice to make the most of them.
  - axaxs 6y ago
    It's funny you say that. Not long ago, one fresh dev was tasked with linting old code. Their first pass was to delete everything that the linter complained about. Hey, I guess they solved the problem!

by l0b0 6y ago

bgdam 6y ago

> Asking people to use TDD for a coding test is probably a bit much since it takes a long time to learn the ins and outs, This hits close to home for me, I was very recently rejected at an interview (a 1 hour pair programming session), because my approach to fixing the algorithm was 'not TDD enough'. I think that it's really dumb to expect people to go full on TDD in an interview session, where the purpose would ostensibly be too demonstrate analytical and programming ability. Couple that with the fact that they didn't even tell me that there was going to be an emphasis on TDD, it basically amounted to wasting about 3 days of my time for the entire interview process. It is unfair that companies can unilaterally make such demands on your time, while themselves not spending more than a few hours.

atomicity 6y ago

The problem is that OP is dealing with work where design is the hard problem. They need to do prototyping without considering all of the faults of their programming language, all of the concurrency bugs they could make, and all of the logical errors they could make. TDD falls apart here because TDD helps you write code that does what you think it does. When you don't even know whether it's possible to implement what you want to implement, TDD doesn't help. I think the TDD model of implementation is a lot better than most sloppy dev workflows I've seen, but I agree with OP that small commits don't work out in this case. When you aren't sure whether something is possible, you need to stay less detail-oriented. To do so, you switch from TDD mode to prototyping mode. Personally, I have so little faith in my prototype code that I always rewrite it.

axaxs 6y ago

This sounds awful. In fact, TDD as a whole is awful. I'm a developer, I can make any awful code pass any test I want.

alpaca128 6y ago
> I'm a developer, I can make any awful code pass any test I want. How is that statement exclusive to TDD or something that makes TDD unviable? TDD isn't about trying to pass some tests no matter how. It's supposed to make you think through the problem and define the interfaces before writing the actual code, when it's still very easy to rearrange and adapt the structure. So that the end result is not awful in the first place.
- axaxs 6y ago
  I think it's just a paradigm difference. For me at least, I think better about tests -after- implementation. A short example. Let's say I had to write a hash function. If I were forced to write a test for it up front, I'd probably do something naive like ensuring the result of hashing("abc") was 123. Now I start on my code. Oh, I need to return 123, easy enough. Tests pass, ship it! If I implemented the function first, I'd then think about pitfalls -in- the code. Let's give it weird input. Let's give it empty things. Let's make sure that for 1000 random strings, the hashes are different. Things like that, because those are things I think about when -implementing- the code, and typically not prior. I'm not saying that to be snide, that's really how my brain would work. I understand everyone is different, so I'm only speaking for myself.
mjfisher 6y ago
I can go one better, and make any program at all compile by removing code with the annoying wiggly red lines under it. The tools and options we have don't exist in a vacuum; you still need good judgement and practice to make the most of them.
- axaxs 6y ago
  It's funny you say that. Not long ago, one fresh dev was tasked with linting old code. Their first pass was to delete everything that the linter complained about. Hey, I guess they solved the problem!