Rails - May 2006 - Is test driven development for newbies?

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.

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 Fowler [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 Baker (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

On May 13, 2006, at 06:33 PM, Brian Hughes wrote:
> 2: <rspec.rubyforge.org>
Pardon the typo. :)

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

-Brian

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.



-- 
Posted via http://www.ruby-forum.com/.

On May 13, 2006, at 07:31 PM, Michael Greenly 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!
:)
> 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 ;)
don''t
need to be re-tested/re-verified in your apps...

-Brian

On 14-mei-2006, at 1:31, Michael Greenly 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

Is test driven development for newbies?

YES YES YES.


On 5/13/06, Brian Hughes <brianvh@alum.dartmouth.org>
wrote:
> On May 13, 2006, at 07:31 PM, Michael Greenly 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! :)
>
> > 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 ;)
don''t
> need to be re-tested/re-verified in your apps...
>
> -Brian
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

> > 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

On 14/05/06, Brian Hughes <brianvh@alum.dartmouth.org>
wrote:
> On May 13, 2006, at 07:31 PM, Michael Greenly 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! :)
>
> > 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 ;)
don''t
> need to be re-tested/re-verified in your apps...
>
> -Brian
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 14 May 2006, at 12:31 am, Michael Greenly 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 ;-)

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 Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com