Hacker News new | past | comments | ask | show | jobs | submit login

The funny thing is that TDD is actually a great way to break paralysis analysis. State what you want your new feature to do, get it working, improve it, or don't... you've got your ass covered so you can always make it more "perfect" later on without worrying about breaking anything. Without the safety net there's a pressure to get it right first time as it might be too risky to change it later.



This is true only once you've decided on your tools, and rails has such an outrageous selection that I can see people getting stuck before they start.

Should I be using Test::Unit or RSpec? Maybe Cucumber? Should I be testing this functionality as unit tests, functional tests or integration tests? Should I seed the database with fixtures or factories? If I want to use factories, should I use Machinist or Factory Girl? How am I going to test client-side functionality? Selenium tests, or webrat or javascript unit tests? If I'm using javascript unit tests, then do I use Jasmine, or QUnit, or Mocha?

The answer to most of these questions is really just a matter of personal preference, but you can see how easy it is to get overwhelmed even after you've decided to do TDD on Rails.


Great perspective. I called my dad last night and he told me he'd been thinking about "this LastPass thing you keep telling me about" and that he wanted to try it out and asked me if it basically was the gold standard or are there other companies that do it better.

I told him that I could discuss the options with him for a half hour but the point isn't to pick the best password manager, the point is to use a password manager. There are 10 different companies in this space and telling him about all of them will only create a barrier to entry. The huge wins you get from the macro-optimization of starting far outweigh any micro-optimizations between different providers.


But that is why Rails promotes defaults. Only once you begin to see shortcomings with the defaults do you need to start looking for something else that may be a better fit.


Ha! Remember this comparison with java back in the day? http://www.youtube.com/watch?v=PQbuyKUaKFo


Even more than that, I've found that TDD allows you to work out in your head how you want everything to work black-box style, and worry about the implementation second. By starting with a list of inputs and outputs that you expect, it gets you started moving toward your goal immediately. And if you don't have that list, then you already know what step one is.


trying to write out documentation on how to use something is as helpful as TDD in some cases for the "making you figure it out before you start".

Where TDD shines is giving you a tiny testbench to see that your implementation is heading in the correct direction before you get too far.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: