Forum: Ruby on Rails evolving to the tdd mindset

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Josh K. (Guest)
on 2007-01-17 21:38
(Received via mailing list)
while reading through Beginning Ruby on Rails E-Commerce, my eyes have
been
really opened up to test driven development and how important it is.

i have a problem though. i don't think like a test driven developer... i
see
these tests, and while they're very insightful on how to write test
code,
what i'm really looking for are testing guidelines. what should i test?
what
should i just assume works, because the code i've used 100 times before
has
always worked?

while going through the book, i'm thinking thins like "i wouldn't have
that
to test and see if the h1 tag was on the page". or then there are things
that i wouldn't even know _how_ to test because examples weren't given
in
the book ;)

i realize that it's a different mindset, and i also realize that it
won't
happen overnight. but what are things that other developers use as a
rule of
thumb in order to decide how their tests should run? what questions can
i
ask myself as i'm writing each action that can help me make decisions or
at
least help train my mind to start thinking about my tests.
Phlip (Guest)
on 2007-01-17 22:52
(Received via mailing list)
Joshua Kieschnick wrote:

> while reading through Beginning Ruby on Rails E-Commerce, my eyes have been
> really opened up to test driven development and how important it is.
>
> i have a problem though. i don't think like a test driven developer... i see
> these tests, and while they're very insightful on how to write test code,
> what i'm really looking for are testing guidelines. what should i test? what
> should i just assume works, because the code i've used 100 times before has
> always worked?

Try never writing (or changing) a line of code until you first have a
failing test case, requesting it to exist.

I'm aware that's really hard. (For example, how in Hell do you write a
test case which checks your onclick contains an Ajax.Request call that
will send the correct parameters to the server? In such situations,
let testing slide.)

If you start that cycle of adding a little test, and adding a little
code, , you will feel more secure about the code, and you will feel
insecure when doing things the old way. And you will debug less, and
manually test the website less.

> while going through the book, i'm thinking thins like "i wouldn't have that
> to test and see if the h1 tag was on the page".

assert_select 'h1', /my title fragment/

Test things that could break invisibly. If that title comes from
simple RHTML, don't bother to test it. If it comes from deep below the
Controllers, test it.

> or then there are things
> that i wouldn't even know _how_ to test because examples weren't given in
> the book ;)

That is the coal-face of TDD research...

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!
Chris G. (Guest)
on 2007-01-17 23:10
Josh K. wrote:
> what i'm really looking for are testing guidelines. what should i test?
> what
> should i just assume works, because the code i've used 100 times before
> has
> always worked?

These are the kinds of questions I had when I was first learning about
TDD. What made a huge difference for me was the book "Pragmatic Unit
Testing in Java with JUnit"
(http://pragmaticprogrammer.com/starter_kit/utj/index.html). It does a
great job of going into the why, when, and how of unit testing in
detail. Yes, it's based on Java, but it's still the best book I've seen
on the fundamentals. (To write my own tests for my Rails projects, I
ended up going back and forth between this book for the theory and the
testing chapter in AWDWR for the implementation details.) I highly
recommend it.
Sam A. (Guest)
on 2007-01-17 23:41
(Received via mailing list)
On 17 Jan 2007, at 9.10 pm, Chris G. wrote:

>
> Josh K. wrote:
>> what i'm really looking for are testing guidelines. what should i
>> test?
>> what
>> should i just assume works, because the code i've used 100 times
>> before
>> has
>> always worked?

Don't worry too much, getting into the TDD/BDD mindset isn't easy if
you've already been a coder for a while. However, read Test-Driven
Development by Kent Beck. After reading it, if you still don't
understand, then you should start to worry :-)

Sam A.

---
http://sam.aaron.name
Jacob A. (Guest)
on 2007-01-18 00:13
(Received via mailing list)
On Wed, Jan 17, 2007 at 12:51:26PM -0600, Joshua Kieschnick wrote:
> i have a problem though. i don't think like a test driven developer... i see
> these tests, and while they're very insightful on how to write test code,
> what i'm really looking for are testing guidelines. what should i test? what
> should i just assume works, because the code i've used 100 times before has
> always worked?

Here's a few of my thoughts on testing.

* Nothing works
As far as I care no piece of code works unless I have a test showing
that it is actually performing in the way I expect it to. That means
that I will test both code I write myself but also stuff I use from
Rails, like f.ex. an AR might have some "validate_uniqueness_of" I would
test those validations too. I know Rails is a pretty well tested piece
of software, so what I'm really testing is my understanding and usage of
Rails.

* Coverage
Use rcov to get an idea of how far you are from base 1. For me base 1 is
100% coverage with rcov. That is, 100% is a minimum. It just tells me
that I have the basics covered. It's not really a measure of the quality
of your tests, but you know that if you're not at 100% somethings
missing.

* Write tests first
I'm unfortunately not very good at doing this myself. But my experience
tells me that writing my tests first gets me much better quality than
writing tests after. Additionally writing tests first is a good way to
"design" the interface to your code as a result code written test first
tends to be clearer and more loosely coupled in my experience.

* Test what matters
I'm not a big fan of testing what is actually in the views of pages. As
far as I'm concerned the views are the place where you get the least
"bang for the buck" testingwise. If there's a problem in a view chances
are that it'll be noticed immediately anyways. As such I tend to focus
my testing on the unit and functional level. Unittests are good for
ensuring that your whole model works as intended. With unittests you can
easily get into all the corner cases and obscure situations of your
model. I like thin controllers so functional testing is mostly a matter
of testing that the controller is actually passing stuff on correctly to
the model and redirecting users as expected.

* Continous integration
If possible one should setup a CI system for running tests automatically
on each commit (you are using version control right? ;-)). This is
beneficial in at least two ways. First it's sometimes easy to forget to
run the tests, with continous integration you'll be notified immediately
if you break something. The second reason is to have a clean slate
environment, perhaps even using another database. Sometimes you might
forget to commit a file or something else machinespecific on your
development machine keeps the tests running when in reality they should
fail. In this case CI will make sure you get notified of this. Right now
Cerberus seems to be a good candidate for easy-to-use CI for Ruby and
Rails.

* Testing is a safety net
One of the big wins of testing and the first time you'll really
appreciate all your hard work is when you one day make a minor change
somewhere which really shouldn't have any impact at all and your tests
fail. I've heard this over and over as the big aha-experience for people
new to testing. Additionally as you tests grow better and better you'll
become more and more confident in reworking your code and doing massive
changes without worrying what you might have broken. The days of "if it
ain't broken, don't fix it" are over, with testing you get the power to
improve your code even when it's working. And this is probably the
biggest advantage of testing, the ability to rely in your code and
change it without hesitation.

* Bugs be gone
Whenever a bug is reported the first thing to do is to write a test
exposing the bug. Once you have this you can fix it and be sure it will
stay gone forever. Over time you might even come to appreciate bugs as
they make your tests even better than they were.

* The flipside
Of course testing is not all fun. It's actually a lot of work to write
tests and being forces to think about the problem before going on a
hack'n'slash in codeland. Additionally tests may make one reluctant to
perform major refactorings as a lot of test code will need to be altered
at the same time. This is actually a major issue which I don't really
know the solution for. When going on a major code rework how to ensure
that tests are still as good as possible.

* Heckle
Recently some of the good chaps over at Seattle.rb released Heckle which
will try to mess with your code to expose weaknesses in your tests. This
might be worth looking but will probably not be worth it until you're
pretty confident in your tests.

I hope this was what you are looking for and gave you some inspiration.

--
Cheers,
- Jacob A.
Phlip (Guest)
on 2007-01-18 01:55
(Received via mailing list)
Jacob A. wrote:

> Here's a few of my thoughts on testing.
>
> * Nothing works

I never worked on public websites before Rails. I understand one
common Best Practice is to set the website up on a test server and
mess with it before rolling the code to live servers.

We don't do that with the Rails projects. The tests all pass, we
commit, deploy with Capistrano, and the live site has the latest
version of the code.

Rails and testing makes us competitive with the non-Lean shops that
take forever to deploy their new versions...

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!
This topic is locked and can not be replied to.