I’m not a paid developer, but I still feel guilty. I thought it might
be entertaining to have a little “programmer confession.” So let’s hear
an answer to this simple question:
What makes you guilty about your Rails development?
Mine is a bad one: I don’t write tests. I understand that TDD makes
sense, but I just don’t do it. I’ve always rationalized “oh I’ll figure
out the whole testing thing on the next app” but 5 or 6 apps deep I’ve
never done it. Hell, I’ve never even run tests for plugins, Typo, or
anything. I skipped the Testing chapter in the Rails book. I know this
clearly makes me a bad person.
Dave T., if you’re reading this, please don’t repossess my copy of
The Pragmatic Programmer!
The rule is: If you’re going to feel guilty you can go ahead and do
anything you want.
Have sex with baby goats or start wars. As long as you know you’re
guilty!
I feel guilty about sleeping late. Also, I sometimes confuse the rules
of JavaScript and
Ruby. This makes me feel stupid but that’s pretty close to feeling
guilty. You know, if
we were really organized right we’d have installed Ruby into the web
browsers and
obsoleted the problem. If I were a consistent person I’d follow that
up by advocating
running JavaScript on the server. But the thought of giving up Ruby
gives me hives. We
are all guilty of imposing “Too many languages” on our systems, to the
detriment of the
managers, customers, and general public.
Also, I feel guilty using easy languages like those instead of machine
language. I used
to be pretty damn good at slinging machine registers and interrupt
masks.
Hey, he admitted it was only one goat… and that the goat reeeeeally
liked
him.
Ironically enough, he passed a consensual goat sex bill under the radar
a
few years back.
Anyhow… I’m guilty of the lack of tests too. I blame tight deadlines,
and
my rookie status of using Ruby and the Rails framework.
That said, I would love to see a screencast of real TDD in action…
maybe
even vs. the non-TDD approach.
or 6 apps deep I’ve
data is valid seems unnecessary to me - after all,
there are all sorts of validatations that can be
placed in models, plus constraints, etc. in the
database. It’s all QA though I suppose… I don’t see
how TDD is faster, but if it is…
Is there a “Non-Testers Anonymous”? I think a 12 step program is in
order here for those of us who haven’t quite perfected out testing
skills.
TDD is faster because you code exactly as much as you need to, and
nothing
more. You lay out the interface to you make it behave properly.
Your’re
right that the tests themselves are overhead, but you end up saving
enough
wasted time to more than make up for it. Your code is lean, and you
have
confidence that it works as advertised.
Then as a bonus, when you are done with a module, you have tests in
place to
make sure the stuff you do next, and a month from now doesn’t break what
you
just did. No more phone calls on Friday at 4pm from screeming clients,
well, less of them anyways.
Pretty soon after you are in a testing mindset, you test even for small
projects. Its habbit, and because they are similar tests to ones you
have
written a thousand times before, they take no extra time at all.
Then you realize that TDD can cure world hunger, decifer who killed
Kennedy,
and land you an invitation to a key swapping party at Uma Thurman’s
house.
After that you realize that TDD just makes you happy, so you start to
apply
it to other aspects of your life.
Test Driven cooking for example -
Make eggs -
Fail! You don’t have eggs
go to the store and buy eggs.
Make eggs -
Pass, you have eggs to cook.
Fail! You didn’t turn on the stove.
Mine is a bad one: I don’t write tests. I understand that TDD makes
sense, but I just don’t do it. I’ve always rationalized “oh I’ll figure
out the whole testing thing on the next app” but 5 or 6 apps deep I’ve
never done it.
I too have had guilty feelings about this and I have partially resolved
the problem by writing tests, but only realy really simple ones.
I don’t do too many unit tests, but it is possible to write a simple
functional test that simply runs an action on a controller and verifies
that the action worked without any unexpected exceptions being thrown.
You don’t have to write lots of assertions that all the right things
have happened. The test still has some value if it runs and nothing
‘blows up’.
Having a simple test for each action on each controller means that you
can be fairly sure that your changes have not prevented something else
from working. For example, you can then remove (what you believe are)
obsolete methods from your models and be pretty sure you have not broken
anything.
Well it works for me and seems to be a reasonable compromise between
lots of work and lots of bugs.
anything. I skipped the Testing chapter in the
Rails book. I know this
clearly makes me a bad person.
I’m guilty of that. I’m currently reading the testing
chapter in the Agile book, attended a Java testing
meeting last night, and can see the value of testing.
But writing so many tests just to make sure retrieved
data is valid seems unnecessary to me - after all,
there are all sorts of validatations that can be
placed in models, plus constraints, etc. in the
database. It’s all QA though I suppose… I don’t see
how TDD is faster, but if it is…
csn
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
the problem by writing tests, but only realy really simple ones.
from working. For example, you can then remove (what you believe are)
obsolete methods from your models and be pretty sure you have not broken
anything.
Well it works for me and seems to be a reasonable compromise between
lots of work and lots of bugs.
These sound like “smoke tests” (as in “connect up all the boxes, turn
them all on, and check that no smoke comes out”) - useful to check that
everything is configured properly. They also sound like tests you have
written after coding the action.
As others have pointed out, TDD is about expressing each tiny piece of
requirement unambiguously (as a test) before coding the solution, and
being able to focus on just what is needed to satisfy that requirement
(pass the test) before moving on to the next one. Reading Kent Beck’s
book on Test Driven Development really impressed me with how small the
steps can be, and how literally he takes “the simplest thing that could
possibly work”. Going to an Agile Summer School last summer confirmed
this for me.
I’ve heard for a long time, and recently been able to see for myself,
that you can clearly see the difference between code developed using TDD
(clean, small tightly focused methods, highly testable) and code
developed “the old way”.
What would everyone think about having a test first challenge for
rails? We could run it sort of like ruby-quiz but for rails and TDD.
What I envision would be something like this:
Come up with specifications for a small rails app with certain
functionality.
Have someone write a full test suite and a reference version of the
app that passes all the test.
Then announce the challenge and only give people the description of
what the app does, a sql dump or schema.rb and a comprehensive test
suite.
Give people like a week to make all the tests pass and then post
everyones app somewhere so everyone else could see how others
approached the problem domain.
I think this would be a cool way for people to learn how to do Rails
TDD in a fun competitive environment.
This might be fun, but it is NOT TDD, as the term is understood by those
who
invented it. TDD is about writing a little bit of test code, then a
little
bit of production code, then refactoring, and repeating over and over
again.
It is NOT about writing a full set of tests before you start on any
code.
The idea is that you’ll always write just enough code to make the next
test
pass (and keep all older tests passing). This process is supposed to
keep
your code as simple as possible, while still meeting the requirements.
I love and practice TDD. It is not a panacea, of course. Every way of
developing software requires smart, hardworking coders and customers to
be
successful. (First person to find a find a method without these
requirements WINS!)
TDD is faster because you code exactly as much as you need to, and
nothing more. You lay out the interface to you make it behave
properly. Your’re right that the tests themselves are overhead, but you
end up saving enough wasted time to more than make up for it.
That’s the first mistake I made. I only properly came to understand it
recently, but tests aren’t overhead at all - they’re what makes it
possible to change things with confidence. Without tests, if I made an
internal change (maybe putting a DRB proxy in instead of a native
object, for example), I had to sit back and rely on user feedback to
tell me if I’d b0rked anything. Now I’ve got a bunch of automated users
sitting in my test/ directory, actively trying to break my application,
that will tell me straight away if they can’t get their job done.
Without screaming.
Funnily enough, I came to software via ASIC design, where automated
testing is so ubiquitous, you almost don’t notice it. It took a few
projects without it to realise how valuable a concept it was…
I have used functional test ONE time. The time I was implementing the
tests was much longer than implementing controller/views.
So I don’t use them anymore, since controller/view code will be pretty
simple anyway.
Unit tests for models are great though. Implementation is fast, and they
are useful.
But my tests pass 80%-90% of the time at the first try if I pay close
attention to the code I write. (review every character you type, and
think of nicer ways) Make sure you don’t hack together things, and it
will be fine.
But I actually do hack together tings if I want to do things as fast as
possible. Most times it results in having a lot of code in your views,
and that results in longer development time because it takes time to
move this code to controller/helpers. It would be better if I started
with helpers right away.
Are there some good books on test-driven development I can check out?
I’m quite intrigued with the concept - I’m brand new to this stuff,
having picked up the pickaxe book and Agile Development with Rails two
days ago.
I am not ready for the challenge but I think it is an EXCELLENT idea.
I hope lots of you will take Ezra up on his idea. I’ll participate
in a challenge a little down the road when I am less of a threat to
my own programming happiness.
And if I may quote DHH (by implication) "ugliness leads to
unhappiness and unhappiness leads to low productivity. Thus…
ugliness leads to low productivity. I am still suffering from coding
ugliness (but it is getting more beautiful day by day).
On Fri, Jan 13, 2006 at 10:25:32AM -0800, Ezra Z. wrote:
suite.
Give people like a week to make all the tests pass and then post
everyones app somewhere so everyone else could see how others
approached the problem domain.
I think this would be a cool way for people to learn how to do Rails
TDD in a fun competitive environment.
Thoughts?
Sounds pretty cool. Definitely worth considering. I’d add the views to
the
provided skeleton, since the functional testing of Rails is at the
controller level, and we don’t want people to spend all their time
dickering
with prettyness instead of writing code to satisfy the test cases.
To make the project a good simulation of TDD, though, you’d need to
provide
a series of test suites, each with a little more functionality than the
last. The instructions to people would be “satisfy all the tests before
starting the next lot” – heh, we could possibly even hack “rake
default” to
add the next lot of test cases when it detects that the test suite
passes
completely.
Oooh, actually, that’s a really cool idea – each time the test suite
completely passes, you get a paragraph or two blurb of what the next
“chunk”
of development is, and more test cases get piled on. Then, when you
immediately re-run rake, more tests fail, and you go around again.
I’m suddenly very enthused for something like this – but unfortunately
I’ve
already signed my weekend away to another project. Darn it. Oh well,
maybe
something to hack on the train (or I could perhaps use my current
project as
the basis for this… hmm…)
