Is TDD really followed in the industry ?

rubyonrails-talk
1

Hey,

I am a rails beginners. I have created a couple of simple applications without following TDD.

I have a question - Do good programmers really follow TDD strictly ? I mean.. Do they follow { 1. Write Test 2. Write Code 3. Refactor } cycle ?

Is Writing tests before Implentation code really significate beyond these TDD books ??

Please clarify .. I am a beginner and I want to grow well in rails atmosphere.

Thanks

2

lucky in ruby wrote:

Hey,

I am a rails beginners. I have created a couple of simple applications without following TDD.

I worked without tests for 8 years. Never again.

I have a question - Do good programmers really follow TDD strictly ? I mean.. Do they follow { 1. Write Test 2. Write Code 3. Refactor } cycle ?

Yes.

Is Writing tests before Implentation code really significate beyond these TDD books ??

Yes.

Please clarify .. I am a beginner and I want to grow well in rails atmosphere.

Thanks

Best,

3

I am a rails beginners. I have created a couple of simple applications

without following TDD.

I have a question - Do good programmers really follow TDD strictly ? I

mean… Do they follow { 1. Write Test 2. Write Code 3. Refactor }

cycle ?

Is Writing tests before Implentation code really significate beyond

these TDD books ??

Absolutely! It’s a matter of habit to get in to, but once you do…

I much prefer developing TDD. It’s not always easy (if you’re taking over an existing codebase, etc) but if you have the chance go for it - you’ll find bugs much earlier in the process which is ALWAYS a good thing :slight_smile:

A lot of companies using Rails are doing things in a very agile/Agile way - automated testing is a key part of that, and it’s always better to test first.

I would say though, that I much prefer feature tests using Cucumber to old Test::Unit tests.

Cheers,

Andy

4

The one time I write code before test is when I am not sure how to achieve what I want to achieve in the app, For example I may wish to get a particular visual layout and am not sure exactly what html I need to generate to get the effect (due to my lack of experience). In that case I will read docs, google and experiment with the code till it is what I want and then knowing the html (which I make sure I now understand) I write the tests. I then comment out the code generating the html and check the tests fail, then put the code back in a bit at a time to make sure the appropriate tests now pass.

What I found amazing when I started with TDD was how quickly I got the stage of writing tests and code to develop the app, often only viewing the app in the browser almost as an afterthought, as I was confident it was going to work anyway.

Colin

5

Excuse to be blunt but I consciously count at least once or more a day that the discipline of writing tests saves my a$$ — and that is conscious, who knows all the other bugs it saves me from. I encourage you to take the time an discipline to learn this method. My first large project I did without tests. Tests dont solve everything but they do mitigate a good portion of the living hell possible without them. I learned this by experience… hopefully you will be smarter :slight_smile:

Practical idea - take two small projects, write one how you would normally and one strictly following tdd. When you are done judge by:

  • The results
  • How you feel about the project and the beauty of your code
  • How confident you are in making changes to the project
6

Any good book or resource to start learning TDD with rails?

7

http://www.google.com/search?q=test+driven+development+with+rails

But even with all these resources, it’s good to keep in mind there’s several options for testing your Rails app.

We use RSpec for unit testing, Cucumber + Webrat + Selenium for integration tests, Factory Girl for factories (instead of fixtures). It all comes down to what you prefer and all I can say is that I really don’t prefer the default Rails testing framework.

Also, if you’re not fairly familiar with Rails in the first place, TDD or BDD may be a bit too much to start off with, especially if test-first development is completely new for you. I wouldn’t recommend it to be honest, you’ll probably give up before having something showing up in your browser.

That said, except on rare occasions where we implement a feature that we haven’t really fleshed out completely, we develop using BDD. Not only does it avoid deep nested bugs, but it also keeps you on track, it’s very tempting to add new “little” features along the way if you haven’t set a clear path to start off with. By testing first, you work towards the goal you set and once you achieve that goal, you move on to adding those nice little extras if there is still a need for them and you can do so without worrying about breaking what you already have.

Best regards

Peter De Berdt

8

I agree you shouldn’t dive into a big project without testing. Small projects to start off with is the way to go. However, as the original poster said, he’s not even familiar with Rails (and probably Ruby as a whole). TDD with no prior knowledge of the concept, the language or the framework you’ll be using… bad idea. TDD should be the goal, but at least get comfortable with the environment imo.

Best regards

Peter De Berdt

9

Andy Jeffries wrote: [...]

I would say though, that I much prefer feature tests using Cucumber to old Test::Unit tests.

Cucumber and Test::Unit are orthogonal, and I believe it's possible to use them together. I love Cucumber, and I highly recommend using RSpec rather than Test::Unit, so I basically agree with your recommendation...just trying to be accurate here. :slight_smile:

Cheers,

Andy

Best,

10

I will second that. My first rails app I gave up doing tdd because was overwhelmed. Second app, it is now second nature. Be good to yourself first… even without tdd IMHO you will still reap great benefits from the framework.

11

Peter De Berdt wrote:

Any good book or resource to start learning TDD with rails?

test driven development with rails - Google Search

But even with all these resources, it's good to keep in mind there's several options for testing your Rails app.

We use RSpec for unit testing, Cucumber + Webrat + Selenium for integration tests, Factory Girl for factories (instead of fixtures). It all comes down to what you prefer and all I can say is that I really don't prefer the default Rails testing framework.

Agreed. (Though I think I prefer Machinist to Factory Girl, and I use little enough JavaScript that Selenium is not usually necessary for me.)

Also, if you're not fairly familiar with Rails in the first place, TDD or BDD may be a bit too much to start off with, especially if test- first development is completely new for you. I wouldn't recommend it to be honest, you'll probably give up before having something showing up in your browser.

I don't think I agree with this at all. I learned Ruby, Rails, and test-first development at the same time -- then again, I'd already had 8 years of Web development experience by that point, and I'm a fast learner. http://www.sitepoint.com/forums/showthread.php?t=381413 was pretty helpful in taking those first steps, though it's perhaps a bit different from how I'd do it today (and it's in PHP). A lot of stuff at http://c2.com/cgi/wiki (Ward's Wiki) might be useful, and there's a good example at Test Driven Development Tutorial Roman Numerals .

There's also an excellent Cucumber presentation at

.

That said, except on rare occasions where we implement a feature that we haven't really fleshed out completely, we develop using BDD.

I don't understand this statement. I would think that implementing a feature that's not completely fleshed out would be *exactly where you'd most want BDD*.

Best,

12

I'll throw in a couple of advantages not yet mentioned:

1) When you're "done" (as if!) the tests are excellent documentation      of what the code is intended to do, for someone stepping in to work      on it for the first time, or even yourself if it's been a while.

2) If you work on multiple projects and wind up putting one aside for a     significant time, there's no better way to refresh your memory on     where you were than to watch the tests run (particularly RSpec).

FWIW,

13

Peter De Berdt wrote: [...]

However, as the original poster said, he's not even familiar with Rails (and probably Ruby as a whole). TDD with no prior knowledge of the concept, the language or the framework you'll be using... bad idea.

In my experience, this is not necessarily a bad idea. As I said in my earlier post, I learned test-first development* and Ruby while learning Rails. I think that, *particularly* when learning a new language and environment, it is important to set up tests so you know if you're doing things right.

Now, I don't always manage to do this myself, particularly if I'm trying to closely follow a tutorial (as with my current slow progress through Real World Haskell). But I think it's worth trying to incorporate tests as soon as you're off the tutorial and trying to write real code.

Discussion about this a couple months ago made me realize that it would be interesting to write a basic Ruby (or other) programming text that taught testing *first*, and then taught the rest of the language syntax only as a way to implement the tests and make them pass.

* I dislike the term "test-driven development". The tests shouldn't drive the development; rather, the user's requirements should.

TDD should be the goal, but at least get comfortable with the environment imo.

Writing tests is a great way to see how the environment behaves...

Best regards

Peter De Berdt

Best,

14

Hassan Schroeder wrote: