TDD is horrible while learning a new language

I'll generalize this and say that TDD is terrible whenever trying to learn new tools. It seems to work really well when you're using the same tools you've always used--frameworks, plugins, gems, libraries, architecture, server stacks, whatever--and the only new area of research is the domain logic and implementation thereof.<p>I'm running into this exact thing right now on a new project that uses some tooling I haven't used before, and I'm doing an awful lot of yak-shaving. Some of it I would have done anyway just writing code with the new tools, but writing effective tests really does require a certain base comfort with the tools.

i disagree. unit tests <i>help</i> 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.<p>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.<p>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.<p>[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.]

I also find TDD to be rather useless when you haven't quite figured out what your architecture is going to be yet. My general process is model -&#62; test -&#62; code. If I can't yet determine my model because my knowledge isn't deep enough yet, the tests are all garbage that will have to be rewritten anyway.<p>I get the argument of tests as interface specification, but I just don't buy it. Some people may not like to model outside of code, aka UML or variants, but any reasonably complicated system needs a high-level concept drawn up before you can safely start pushing through individual components.<p>I love TDD for known problem/known solution scenarios, but I've found it to be a pretty bad time sink for unknown solution combinations. YMMV, and I think everyone finds their own comfort zone with TDD after some experimentation. The big lessons for me were that [x] testing is a net time saver versus the spray and pray code like hell strategy (yes, this makes sense before you realize you're not a programming messiah after all!) and that taking the perspective of a code consumer helps you write more fluent APIs.

I'm religiously devoted to TDD and understand the 'dirty' feeling that comes from writing any code without it.<p>But its totally fine to learn new languages and try out new stuff without it. TDD only needs to be enforced on code going into production.

This is a fair argument to make: "Remove unnecessary layers or complexity when learning new languages." And I also don't TDD when learning a new language - in the beginning.<p>However TDD (when done pragmatically) is actually a great way to dive into a language. The thought process of mocking the file system is actually _where_ you learn about the language/libraries/frameworks. You have to understand those APIs a little bit before you can properly mock them.<p><i>... like how do I run the tests?</i> I run into this a lot when I code as well. But I have to remind myself that I don't need a runner from a framework in order to do TDD. Don't even need a framework.<p>There is nothing about TDD that says you have to use any unit testing library. It's a process. And if understood properly and used pragmatically can be an excellent way to learn a new language.

Some people try to force/shame TDD on others because it's more "efficient". "You're going to have to do it anyways." they say. Well, it's your mind and it's your time not theirs. Only you will know what's right for you. If TDD doesn't work out while learning a language then drop it. If it works out then great. I'm sensing this TDD arrogance that really pisses me off. It's not the only way to write a program. It all depends on who/what the program is written for.

I think the better approach would be something to break each piece down into something that can be ingrained over time. I find it much better to hack at a language in a text editor and compiler first, then move towards an IDE if applicable. Sometimes I find that I get more comfortable in a text editor and the IDE is just more overhead than I need. I think something like this would be a better approach:<p>1. (If Applicable) How do I compile the code? What is the shortcut?<p>2. How to I get something to display on the screen/website?<p>3. How do I build unit tests in this language?<p>4. How do I run the unit tests?<p>5. Are there any tools like AutoTest available?<p>6. What are the preferred source control tools?<p>7. What frameworks are there? Are any of them by far the leader?<p>This can be expanded as far as you want to take it, but I think this approach would make things a little easier to swallow. By focusing on one question at a time, I believe someone would be less likely to bite off more than they could chew before they were ready for it.

I'm glad to see I'm not the only one that feels this way. Anytime a decent amount of "newness" creeps into my process I find TDD difficult. I usually resolve this by doing a spike, figuring out what I need to do, throw away that code and then do it again under TDD.

Developer uses wrong tool for the job, complains on blog. When you're learning a new language, learn the language. The code you're writing during learning probably isn't worth keeping around anyways (it's likely non-idiomatic and carries over habits of other languages).<p>Once you feel comfortable and want to write something a bit more stable, bring in unit tests if you feel the need. I find tests great for establishing how I want the API to be since the test is API-in-use and quickly shows flaws in ease-of-use. But, if you're just learning you don't need that extra layer on top of all the other things you're trying to learn.

I learn new languages by writing tests to test my knowledge of new language.

Apparently <i>TDD</i> is a <i>test-driven development</i>.

I disagree. Code unsuitable for learning makes for hard testing. For a reasonably good version, try <a href="http://rubykoans.com" rel="nofollow">http://rubykoans.com</a>.

depends..<p>I have found that when learning a new language that if I have someone's unit tests it makes it easier. BUT, I have a few languages of exp such as C/C++, COBOL, assembly, Pascal, Forth, Java, Groovy, Python, etc.<p>In most cases, TDD is not to be used with beginners unless its used as pair programming. In fact if you read back when TDD was established that was one of the use cases for paired-programming..

I think this is a specialized instance of the general advice to not test code which has not yet been written. If you're writing a test ahead of the code which it tests, you'd better have every single line of that code already written in your head.