It seems odd that I’ve not seen this question here before, but maybe I
missed it (or just don’t get it on some deeper level!):
My current project require some libraries (e.g., CSV) that have been
altered in 1.9. It’s be comforting to know that when the time comes
there’s some quick way to flag the areas of my code that need attention
if they’re to run OK in 1.9. Yeah, it’s be great if I had a test suite.
but honestly, it’s all I can do to get the code together in the first
place. Tests are high on my todo list, but my need for my current
project is higher by far, and I’m close to having a complete function
set, so tests aren’t on the menu today.
So - is there some 1.8-to-1.9 scanner or whatever?
Thanks,
t.
–
Tom C., MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< [email protected] >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
So - is there some 1.8-to-1.9 scanner or whatever?
Thanks,
t.
I’m puzzled by the underwhelming response to this question. It is a
genuine one, for me, as I’ve not gone through a transition like this
before, being new to this programming community.
I’m just curious about how others handle, or will handle, this problem.
Surely one doesn’t just launch the boat and hope there are no leaks,
yes? There has to be a better way. But…for me, it’s far from obvious.
Still hoping for some response…
Tom
–
Tom C., MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< [email protected] >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
It’s be comforting to know that when the time comes
there’s some quick way to flag the areas of my code that need
attention if they’re to run OK in 1.9. Yeah, it’s be great if I had a
test suite. but honestly, it’s all I can do to get the code together
in the first place.
So - is there some 1.8-to-1.9 scanner or whatever?
I’m puzzled by the underwhelming response to this question.
I’m just curious about how others handle, or will handle, this problem.
You appear to have answered your own question before even asking it.
I’m not a Ruby whiz, but AIUI, the only way to build robust systems with
dynamic languages is to test thoroughly.
Surely one doesn’t just launch the boat and hope there are no leaks,
yes?
[…]
is a way to go faster over time, not slower.
Regards,
Bill
Bill, Jeff - thanks. Your responses are genuinely helpful to me. I’m
highly educated in some fields, but not in this one, so I’m often in
need of guidance. I’ve wondered if I might have made a strategic error
by deciding to defer testing, especially when I implement a new feature
and then have to throw a bunch of ad-hoc tests at the code to make sure
I’m still advancing on all fronts. OK, I get the message. Changing
strategies, tonight. Sigh. I hope test writing goes faster than
generating the core code (which, being Ruby, really has gone rather
smoothly).
Thanks again (he says with some chagrin).
t.
–
Tom C., MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< [email protected] >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
[…] It’s be comforting to know that when the time comes
there’s some quick way to flag the areas of my code that need
attention if they’re to run OK in 1.9. Yeah, it’s be great if I had a
test suite. but honestly, it’s all I can do to get the code together
in the first place. Tests are high on my todo list, but my need for my
current project is higher by far, and I’m close to having a complete
function set, so tests aren’t on the menu today.
[…]
Surely one doesn’t just launch the boat and hope there are no leaks,
yes? There has to be a better way.
I doubt this is the answer you were hoping for. But deferring
writing tests is not generally a strategy for completing a
working project sooner.
If your need for your current project is high, having a
supporting network of unit tests continually verifying that
your features are still working as you develop new features,
is a way to go faster over time, not slower.
One effective strategy for not falling behind in writing tests,
is to write a small test first (!) to verify a bit of
functionality you are about to implement in code.
For more info, see “Test-Driven Development Cycle”, at:
[…] I hope test writing goes faster than
generating the core code (which, being Ruby, really has gone
rather smoothly).
Myself, I’d been programming for about 17 years before I first
read about TDD a decade ago. To this day, I often have to
cajole myself a little bit to proceed with writing tests first,
because it’s not something i find ‘easy’, but ‘worth it’.
In the past decade I’ve never yet regretted writing tests
first. A number of times, however, I have come to regret
taking shortcuts with something that was supposed to be a
knock-off short-term project, where contrary to my predictions
it had morphed into a longer-term ongoing project where I
began to sorely regret having omitted writing unit tests from
the very beginning.
. . . So again, I don’t find TDD easy; but worth-it.
Myself, I’d been programming for about 17 years before I first
the very beginning.
Thanks Bill. I appreciate reading about your experience. Perhaps I can
shortcut my own development a bit, with help from more experienced folks
such as you.
t.
–
Tom C., MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< [email protected] >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
