Ask HN: Should I employ TDD as a Rails beginner? | Hacker News Reader

Ask HN: Should I employ TDD as a Rails beginner?

3 pointswallawe8 comments

I've seen a lot of discussion about why TDD is good, and why some people feel that it's unnecessary in many circumstances. My understanding is that if you are writing a large scale application that will involve thousands of lines of code and will need maintenance for years, then yes, TDD is certainly a good way to go.

My question, though, is will TDD help me as a beginner to Rails when I am simply trying to get the core concepts and write small apps that get more experience under my belt. My intuition is that TDD is extraneous at this point and slows down the instant gratification factor that motivates me to do more and learn quicker. What are your experiences with it and did it abet your learning process?

View on HN

As a beginner, you won't be building anything big, probably. Focus on learning the stack, the language, MVC. Get to know the libraries. When you are comfortable with that, learn how to test.

Now, I believe 100% test coverage is plain silly. There are things you don't really have to test, and you are the only one who can tell.

I just started building a new app, and haven't done any testing until I was half-way through the first iteration (what I considered to be my first public alpha). I wrote a few tests to make sure the functionality I'd implemented would still work when I changed the code, then I moved to a more TDD dev style.

I wrote a few (maybe 10) tests for things I wasn't sure how they'd behave, noticed I could fix some of my code.

So, TDD can help you, for sure. But don't get too caught up in writing tests if it's getting in the way of actually writing your code.

>Now, I believe 100% test coverage is plain silly.

Agreed with this for sure. It makes maintaining tests unsustainable and time consuming to write. Cover your bases cases and make sure that important failure cases are covered. Don't try cover every possible iteration under the sun. I find that well written tests should almost read like executable documentation.

Also, I like to add a test for something every time someone reports a bug, to make sure there are no regressions (specially if it's a security problem). It also helps reproducing the bug and documenting it.

Great. Thanks for this. I am still trying to understand the intricacies of MVC architecture if that gives you any indication of my experience. I am a front end guy and have worked in the Views layer a good bit but this will be my first real language (Ruby) and framework. I felt like I was trying to cram too much in all at once. I think I will definitely wait to learn more about testing.

How is your programming experience overall? I'd suggest learning ruby first, rails later.

HTML, CSS and a little bit of Javascript/jQuery... I'm self taught, just finished an internship in front end dev at livinsocial, but want to get down to the real stuff, you know. But I'll take your advice I think and learn a little more about Ruby before continuing with all these Rails tutorials and what not.

I have been learning ROR for the last 2 years. The two things I would go back and do more of is write tests and write more straight ruby.

Writing tests for your models should have you covered. You can skip testing the controllers & views.

The longer you go without writing tests the harder it is to start.

If you skip TDD then you should make sure that you take the time to build out test cases with full coverage.

I can't tell you the number of times I have made a change then run regression testing and found unforeseen failures which I wouldn't have caught without my test cases.

Reply on news.ycombinator.com