Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Ruby

Why is tests so boring and how can i get over it?

So is it just me or are tests very boring? I love Ruby on Rails but there is only one thing i have a problem getting over, and that is tests.

I'm used to write code and then i test it in my browser and if it works it works and if it breaks it breaks and i then attempt to fix it and then i repeat my browser tests. So the whole concept of writing a failing test first and see it fail and then write the code to fix it seem a bit alien to me.

I do understand on a intelligent plane that TDD is a good thing and that i should be using it.. but i have a hard time finding the motivation to learn that to and at the same time not having it kill all the fun i have when developing cool stuff with rails :)

So how does one get over this? and where should i start?

2 Answers

Since no one is jumping in to give an answer I will take a stab at your questions.

TDD: Yes, it is a pain. I think it was on the Ruby Rogues podcast where they were talking about how hard it is to do TDD when first starting out (sorry, no clue as to the episode). As a new dev, you are often in the dark as to if you are really covering the use case you are testing for, you may not even have a good grasp on how to write the code the code that would produce a good test. That said, TDD is also pretty cool...

While writing code twice sucks, there is this really cool thing that happens. Once you can get a good test down and go through red, green, refactor, you have that test forever. Every time you type rspec in the terminal afterwards, you verify that you didn't make some small change off in left field that somehow tied back to that little bit of code and subsequently flubbed up that part of the app that you just knew you had working like a charm. In fact, if you are doing the Odot series and running your full test suite, not just the individual files like Jason does, you will catch several issues long before Jason finds them in the videos.

Again, I can't really recall where I picked up this advice and, as such, can't vouch for whether or not it's good practice but here's my game plan: Start with integration tests. Try to cover the action the user would take as best as you can. Write code to get to green. Don't worry about writing code first and then going back to make your tests. Heck, don't worry about making a whole branch and writing tons of code without tests but do try to go back at some point and add the tests in. Taking on TDD in small, steady steps will give you the freedom you want when starting out while still easing you into writing good tests. It will also serve to drive home its benefits and allow you to realize TDD as the tool it is, not just the extra pain in the ass step of writing code.

Hope that helps to lighten the load a little! Cheers!

Thanks for these thoughts and advices :) I've been looking into Rspec and been watching a number of workshop videos from Railsconf etc with Rspec and integration tests and starting to get the hang of it. I just have to accept that i wont be able to go from 0 to 100% TDD/BDD overnight.. that i need to take baby steps in the beginning.