Is test driven development for newbies?

Rails
1

I’m still reading other people’s code and going over the books. As I
was doing this a question sprang up in my mind.

Is it wise for total newbies to attempt test driven development from the
start?

Basically, if you’re a newbie like me, chances are your tests might
even be broken themselves. Or will attempting to write tests be good
practice for actual coding as well?

Obviously, one of the things holding me back is not knowing where to
start. Would attempting test driven development be a valid approach
or best left to those with a little more experience?

On a semi-related topic, can ZenTest be used with the new “integration
testing” in 1.1 ?

Thank you all in advance.

2

On May 13, 2006, at 06:03 PM, SB wrote:

I’m still reading other people’s code and going over the books. As I
was doing this a question sprang up in my mind.

Is it wise for total newbies to attempt test driven development
from the start?

I’m not sure this is a simple yes/no kind of question. I’d say there
are three types of “newbies”: those new to programming, at all; those
new to programming in Rails; and those new to the concepts of TDD/
BDD. The closer you are to being the third, the more likely it is
you’ll be able to pick up TDD, especially as it pertains to your
Rails programming.

Basically, if you’re a newbie like me, chances are your tests might
even be broken themselves. Or will attempting to write tests be good
practice for actual coding as well?

From a TDD perspective, you always start with “broken” tests. It is
the process by which you program to make your tests pass, and then
write more tests, that puts you on the TDD path. Obviously, when you
start out you won’t be creating the most relevant tests, but I would
say that any test that actually exercises your code isn’t a bad test.
It may be superfluous, or even redundant, but if it’s testing
functionality/behavior that needs to be in your app, then correcting
that test is helping you with your progress.

Obviously, one of the things holding me back is not knowing where to
start. Would attempting test driven development be a valid approach
or best left to those with a little more experience?

Looking to integrate TDD (or BDD) is one of the ways that you can
become more agile in your development practices and that is
definitely a good thing. However, starting with TDD can be difficult
when you don’t have a pair to program with, another cornerstone of
Agile Development. You don’t expressly need a pair to do good TDD,
but having an experienced pair, especially when you are first
learning, is a great way to get over those initial humps. One of the
things that my TDD instructor always said was, “writing that first
test is always the hardest.”

If you don’t have a pair, but you still want to try to get into TDD,
one of the things that really helped me was the first chapter of
Refactoring, by Martin F. [1]. Fowler has a nice little example
program (written in Java, but easily mappable to Ruby). What I did,
while following along with his intro to refactoring, was to build his
program in Ruby and build a test suite that verified the code in it’s
initial state. Then, while performing the refactoring examples in the
rest of that chapter, I first wrote tests that I knew would fail, so
that I could verify my refactoring steps in each of his examples.

I found this to be a great help, because I already had some tests so
writing more tests, TDD style, was quite simple, and I didn’t really
have to think about the code I was writing because I was following
the examples. But the key thing is that none of his examples included
the needed tests, so that ended up being by focus for the exercises.
It really helped to solidify the value of TDD, which I had only
recently gotten into, thanks to the Canada on Rails workshop by
Steven B. (my instructor ;).

Obviously, I can’t say if this method would be helpful for anyone
else, but I definitely liked the feel of the process. It was almost
like Fowler was my programming pair, with him “writing” the code that
passed my tests. As a slight side note, I was actually doing this as
a way to teach myself rSpec [2] and BDD [3], not specifically
Test::Unit and TDD, but the process would be exactly the same.

On a semi-related topic, can ZenTest be used with the new “integration
testing” in 1.1 ?

This is something that I don’t know. I haven’t done any work with
ZenTest as of yet…

1: http://www.amazon.com/exec/obidos/ASIN/0201485672
2: <rspec.rubyforge.org>
3: <http://blog.daveastels.com/articles/2005/07/05/a-new-look-at-test-
driven-development>

-Brian

3

On May 13, 2006, at 06:33 PM, Brian H. wrote:

2: <rspec.rubyforge.org>

Pardon the typo. :slight_smile:

Obviously, this should be http://rspec.rubyforge.org/…

-Brian

4

SB wrote:

I’m still reading other people’s code and going over the books. As I
was doing this a question sprang up in my mind.

Is it wise for total newbies to attempt test driven development from the
start?

Basically, if you’re a newbie like me, chances are your tests might
even be broken themselves. Or will attempting to write tests be good
practice for actual coding as well?

Obviously, one of the things holding me back is not knowing where to
start. Would attempting test driven development be a valid approach
or best left to those with a little more experience?

On a semi-related topic, can ZenTest be used with the new “integration
testing” in 1.1 ?

Thank you all in advance.

In the end it doesn’t really matter if the test was written before or
after the code what does matter is how much code coverage your tests
have.

I’d recomend writing the tests before the code if you understand the
problem and after the code if you don’t.

I’d also recomend working in very small units. If you write a new
method you should have written the tests for it before you move on.

Regardless I’d always write tests first when fixing bugs. Write a test
that reveals the bug and then fix the code.

The hardest thing to learn in test driven development is when not to
write a test.

5

On May 13, 2006, at 07:31 PM, Michael G. wrote:

In the end it doesn’t really matter if the test was written before or
after the code what does matter is how much code coverage your tests
have.

I’m not sure I agree with the premise of this statement, but the
conclusion is pretty good. Starting with the test can actually do a
whole lot to improve the way you write your code. They are also your
security blanket for when you need to modify your code, either to add
new behavior, or to refactor existing behavior to make your old code
better.

I’d recomend writing the tests before the code if you understand the
problem and after the code if you don’t.

I’d recommend not starting to write any app code, if you don’t fully
understand the problem. Using tests you can help to describe/frame/
model the problem that you want your new code to solve. That’s one of
the big ways that TDD can help you write better code.

I’d also recomend working in very small units. If you write a new
method you should have written the tests for it before you move on.

Agreed, mostly. You definitely want to make sure that the behavior
you just added is thoroughly tested before you decide to add more
behavior. Otherwise, you won’t know in what ways your new behavior
impacts everything you’ve already done.

Regardless I’d always write tests first when fixing bugs. Write a
test
that reveals the bug and then fix the code.

Exactly. If this methodology makes sense to you, then I would say you
should simply consider every new function/feature you want to add to
your app a “bug” in the current code. Write the tests, which should
fail, to verify that bug and then write the code to make those tests
pass. Suddenly you’re doing TDD and you didn’t even know it! :slight_smile:

The hardest thing to learn in test driven development is when not to
write a test.

Perhaps another way to look at this would be: one of the hardest
things to learn is what behavior needs to be tested by you, vs.
behavior that you rely upon, that has already been tested. However, I
would say that you don’t really need to focus on this when you are
starting out. Test everything in your Rails app that you feel needs
testing, especially at the Unit test level. Eventually, you will
learn which assertions (or specifications, for you BDD’ers :wink: don’t
need to be re-tested/re-verified in your apps…

-Brian

6

Is test driven development for newbies?

YES YES YES.

7

On 14-mei-2006, at 1:31, Michael G. wrote:

e if you understand the
problem and after the code if you don’t.

I’d also recomend working in very small units. If you write a new
method you should have written the tests for it before you move on.

The idea here is that a test also gives you an extremely clear,
formalized description of WHAT your method should do. After you have
written a test you know much better what you rmethod should do, and
why. If you can’t formalize a method with a test, maybe you don’t
need that method or you don’t know how to write it good enough (yet).

I wish someone forced TDD upon me when I was a newbie.

Julian ‘Julik’ Tarkhanov
please send all personal mail to
me at julik.nl

8

I’d recomend writing the tests before the code if you understand the
problem and after the code if you don’t.

I’d recommend not starting to write any app code, if you don’t fully
understand the problem. Using tests you can help to describe/frame/
model the problem that you want your new code to solve. That’s one of
the big ways that TDD can help you write better code.

In my experience, if you don’t fully understand the problem, writing
some code is a great way to get to understand it. I often start my
program over at least three times, writing it really scrappily the
first couple of times, but each time getting to understand the problem
(as well as how to tackle it) better.

As for starting out with TDD… it’s a completely different way of
programming, and if your new to programming I would say (albeit quite
reservedly) that now’s the best time to learn TDD if that’s the way
you’re eventually going to go.

-Nathan

9

On 14 May 2006, at 12:31 am, Michael G. wrote:

In the end it doesn’t really matter if the test was written before or
after the code what does matter is how much code coverage your tests
have.

I’m not sure this is entirely true. If you write the tests after the
code, how can you be sure they’re really testing the functionality?
The idea of TDD is that you write the test, it fails, then you write
enough code to make it pass. To use a trivial example, this test will
pass:

def test_my_method
expected_result = 42
actual result = my_method “ultimate answer”
assert_equal 42, expected_result
end

But because of the typo, you’re not actually testing the method
(which probably works fine anyway). Years later, someone reworks
my_method, and suddenly it starts returning 24 with that input. You
spend ages debugging whatever problem that causes elsewhere, because
you’re convinced you’ve got a unit test that proves it returns 42, so
you don’t bother looking in that method.

If you’d written the test first, it would have been obvious something
was wrong when the test passed before you’d written the code it was
supposed to be testing.

what does matter is how much code coverage your tests have.

Being careful, of course, not to confuse code coverage as reported by
something like rcov with actual test coverage. It’s easy to exercise
all the lines of code in a method without actually proving any
functionality.

Kerry

PS. To answer the original question, I’d say yes. TDD is A Good
Thing, and if you can get in the habit early, you ought to avoid a
lot of the pain that the rest of us have been through :wink:

10

On May 13, 2006, at 3:03 PM, SB wrote:

On a semi-related topic, can ZenTest be used with the new “integration
testing” in 1.1 ?

Since integration tests aren’t unit tests ZenTest doesn’t currently
work with them.

We would like to support working with integration tests but we don’t
know how that would work. We cover that aspect with controller tests.

–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com