Is TDD really followed in the industry ?

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

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,

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

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

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

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

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

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

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,

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.

Peter De Berdt wrote:

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

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.

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
http://www.xpsd.org/cgi-bin/wiki?TestDrivenDevelopmentTutorialRomanNumerals
.

There's also an excellent Cucumber presentation at
http://www.slideshare.net/josephwilk/outsidein-development-with-cucumber-and-rspec
.

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,

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,

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,

Hassan Schroeder wrote: