3 ms·

i disagree. unit tests help when learning a new language, because you can write a test for one very specific piece of functionality and then use it to test whe

i disagree. unit tests help when learning a new language, because you can write a test for one very specific piece of functionality and then use it to test whether you've got things right. in the example given, don't mock out the file system, just use it. hard-code your paths. you can go back and fix that later - what you're doing now is getting basic tests sketched out so that you can learn. so you're confusing "learning a language" with "writing a complete, portable system". of course you can't do the latter while doing the former - you need to make compromises. but ignoring tests is throwing the baby out with the bathwater. perfect is being the enemy of good. [and i am not just bullshitting here - last week i was learning go and this is exactly what i did. the go getting started docs are very clear about how to run tests, and having tests to check i was understanding really helped.]

rauljara 15y ago
I think there is a middle ground. I absolutely agree with the author that test driven development sucks when learning. But that's not to say never write tests while learning. There's a huge different between writing some tests and test driven development. When learning, I often find it's most helpful to just plunge in, then when something isn't working, go back and write tests to try and hone in on the problem. Then more tests to make sure my solution works for edge cases. I find this is helpful even when I'm not learning a new language, and just when I'm trying to do something new enough that I can't see the outline in my head when I start. It's odd how sometimes TDD helps you break down complexity into manageable chunks, and sometimes it front loads complexity, and forces you to solve problems you aren't capable of handling quite yet. Whenever TDD is making me bang my head, I tend to skip it for the moment and come back to it when it's helpful again.
- Argorak 15y ago
  I have the following rule of thumb: I write the test in the moment when I know for sure how an Interface/Feature should behave. If i know it before the implementation, I write the test first. Most of the time, I start programming and write tests for everything that gets nailed down. If I am in completely new ground, I start playing and do not test beyond "run and see".

rauljara 15y ago

I think there is a middle ground. I absolutely agree with the author that test driven development sucks when learning. But that's not to say never write tests while learning. There's a huge different between writing some tests and test driven development. When learning, I often find it's most helpful to just plunge in, then when something isn't working, go back and write tests to try and hone in on the problem. Then more tests to make sure my solution works for edge cases. I find this is helpful even when I'm not learning a new language, and just when I'm trying to do something new enough that I can't see the outline in my head when I start. It's odd how sometimes TDD helps you break down complexity into manageable chunks, and sometimes it front loads complexity, and forces you to solve problems you aren't capable of handling quite yet. Whenever TDD is making me bang my head, I tend to skip it for the moment and come back to it when it's helpful again.

Argorak 15y ago
I have the following rule of thumb: I write the test in the moment when I know for sure how an Interface/Feature should behave. If i know it before the implementation, I write the test first. Most of the time, I start programming and write tests for everything that gets nailed down. If I am in completely new ground, I start playing and do not test beyond "run and see".