Comment by jrochkind1 | Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

As far as writing tests... I'm sure you are testing your code manually yourself already, right? When you make a change, you do something(s) to make sure your change had the effect you wanted, and your software still worked. You just do it yourself, manually, and do different things every time of course.

Take those things, write automated tests to test them. Run the automated tests instead of testing manually, every time you can. Especially when making changes don't run the software yourself to see if your changes did what you wanted, write a test to do it and run that. The first time one of your tests catches a bug that you never would have expected, you'll be hooked.

"Test-Driven Development" actually refers to (almost) always writing the tests _before_ you write the code they test. Not everyone subscribes to this, at least universally. I wouldn't worry about that for now, I think if you just start writing automated tests every time you would have been manually testing, you'll be on the path and things will fall into place.

This is the point. You are most likely already testing your code (logging, printing, or the like).

I learned how to write tests and I was sold on the value of TDD only after I was in the middle of writing a non-trivial, multi-module client/server app. Right now, you think "I don't need to write tests for my penticons library, because I know it works." That's understandable. But as soon as you start incorporating it into other projects, or you extend it with other projects, having tests will make the process so much simpler.

Think about it this way: computing is essentially a way to repeatedly do things really quickly. I could take a pencil and a paper and write the numbers from 1-100 without too much trouble. But when that number is over 1000, or if instead of simply writing the number you perform some tedious formula, then you start to yearn for something like a `for` loop control structure.

The same with testing. Once you have a bunch of moving pieces, and every change you make you find yourself diving into the repl for 10 minutes doing the same thing over, and over, and over... you will actively WANT to know how to test.

So don't sweat it. Learn it if you want. Sooner or later, you're going to _need_ and _want_ to know how to write good tests, simply to save yourself the hassle.

I think Thoughtbot did a nice job of explaining TDD in this 1 hr video (playback speed was increased). Its part 1 or part 2 I forget.

My favorite part is when Josh Clayton excitedly said "Writing our tests is the fun part! Failed tests tell you what to do next!". It was a sort of an aha moment in Rails for me where everything came together.

Moreover, the emphasis was on integration testing (Capybara/Rspec), which I could more easily grok and see the importance, then say unit testing.

Here's a link to the Integration Testing Videos and I hope they could publish this for every one to see freely. I personally feel this was an eye opener to me, and could possibly be one for others as well.

https://upcase.com/test-driven-rails

P.S. I want Thoughtbot to make more real-world applicable quick-cut videos (e.g. Proper usage of the GH PR/Merge Model would be great). The weekly iteration is interesting, but its too conversational. I like rehearsed sentences that quickly convey the knowledge to me. That's the missing piece for me to subscribe.

Reply on news.ycombinator.com