my 2 cents worth… i personally like the feel autotest gives.
especially for TDD. but hey… no experience. only tryouts and
screencasts.
Yeah autotest definitely looks cool in $9 screencasts, but when it comes
to developing a real application that has a few more features than a
blog or a weather forecast parser, you will eventually turn autospec
off.
As you said, the best solution is to get started now!
Ram wrote:
<Yikes!>
ok that was some intense stuff. I dint understand a lot of stuff going
around because, as established before, I dont have experience writing
tests.
But the following are the things Im taking out of this discussion.
- jump in the dirt. Do TDD for your existing app by starting all over
again if you have to. Thats the only way to go (?) / thats the best
way to go to become a better programmer (?)
Starting over, as Phlip suggested, is pretty drastic, but it will make
sure that everything is tested.
- i dont absolutely need any external tools besides test::unit.
Right, although you should try RSpec as a replacement for Test::Unit and
see which you prefer.
I
probably would use the right tools if i ever felt the need for them in
the first place
Huh?
- use fixtures when I have to test something that uses complex
associations between models. especially when the alternative is to
spend a lot of time and brain on mocking/stubbing them instead. (I
have to mention I dont know the difference/similarities/functions of
mocking and stubbing completely)
Check out Martin F.'s article “Mocks aren’t Stubs”, as well as the
RSpec docs. There’s also a hell of a lot of info in the wiki at c2.com,
though some of it may not apply to what you’re doing…
- i dont have any client documentation to show for these tests. theyre
only for the sake of testing my code itself. So ill skip over RSpec
and Cucumber (until i feel a need for them)
Cucumber is definitely for client-documentation-type tests. RSpec,
however, is useful as a replacement for Test::Unit if (like me) you find
that it’s easier to use it for unit tests. (Phlip’s characterization of
RSpec is IMHO inaccurate.)
- test code keeps evolving. I need to optimize test code as much (or
more ?) as i optimize dev code.
Maybe. But differently. Optimize test code for readability and
accuracy – unlike production code, you’re not going to be running
thousands of tests every second. 
and tests breaking out of nowhere will
be a way of life (?)
Perhaps. At least you’ll know right away when something needs work.
i am going to be adding features to the app in between too. anything I
have to keep in mind while doing that?
Try to get everything working before adding the next feature.
when do I start on integration and functional tests?
Good question. And many Rails developers are less gung-ho about these
than about unit tests. (I’m one such developer at the moment, so I don’t
really have a good answer for you yet.)
Also, any good articles that could help me gain some perspective on
the task i have ahead of me?
Other than the c2 wiki…hmmm. There’s an interesting forum thread on
SimpleTest (PHP) that was very helpful to me…I’ll see if I can dig up
the URL. Phlip, do I remember correctly that you’ve got some stuff
around the Web on the subject?
my 2 cents worth… i personally like the feel autotest gives.
especially for TDD. but hey… no experience. only tryouts and
screencasts.
Autotest is just about essential for TDD. On Mac OS, I find it helpful
to integrate it with Growl (there are a number of ways to do that – a
search should turn them up).
Please DO let me know if I have taken away the right things from here
to get started with writing tests for my existing app.
I think so.
I hope this discussion goes further and provides insights for many
more in my place.Thanks Fernando, Marnen, Phlip, Brandon and Hans
You’re welcome! Good luck.
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Thanks for the responses to all my concerns. And I will take your
advice and give RSpec a go too. It definitely is more appealing to the
eyes at least on the test method name level (which is how much i know
of RSpec +/ test::unit )
Huh?
I meant that once i get into writing tests, ill probably know what
tools i need if at all i need them.
good point well made … I have it installed anyway so Ill go along
with it until it starts getting in my way
I don’t think that this is a good idea at all.
Definitely start testing immediately but I wouldn’t rewrite the app at all.
That is sweet music to my lazy ears :D. The whole reason ive
conveniently ignored writing tests for so long is because its
daunting. Rewriting the whole app and doing it the TDD way makes it
even more daunting! I must say though that I realize rewriting with
TDD is probably gonna do more good than covering my code with tests
now. It will make me revisit my app and clarify requirements and
functionality and help me understand my app itself a whole lot better
overall.
But for now, I think im gonna go with writing tests bitwise, covering
existing code. If i feel insecure about it at some point, maybe ill
rewrite with TDD to give the app a more solid foundation. Ive spent
months on this app and rewriting with TDD is just too much added time
investment.
The Comment Driven Development part is very close to my situation
right now. Its an approach that I probably wouldve taken naturally out
of necessity rather than in order to follow a technique. Thanks a
lot for mentioning that. I will look it up in detail.
Cucumber is not just for client documentation but does end-to-end or full-stack testing which is useful for getting as-close-as-the-client-experience testing
That is actually a good point. But when do I start writing full stack
tests? or integration and functional tests too for that matter?
Does one always start writing tests with unit tests and work through
functional, integration and then full-stack-tests? Isnt that like
going from backend to frontend? Would that be the right approach for
ANY kind of application? Even if its largely user centric and has got
very little magic going on in the models?
On Apr 18, 12:35 pm, Andrew T. [email protected]
On Sat, Apr 18, 2009 at 10:12 AM, Ram [email protected]
wrote:
ANY kind of application? Even if its largely user centric and has got
very little magic going on in the models?
Start writing integration tests immediately as the first step, then
work down to view, controller and then unit tests
You want to first cover the expectation and then drill down into the
implementation detail.
I found that when writing Cucumber scenarios on an existing project,
it clarified my thinking around how I already expected features to
work
If I was only able to write one kind of test, it would be integration
or full-stack tests.
The rest of the tests are great because they document how you want
various functionality to work at a technical level but the core of an
app is to get it used (and working) for a customer and that is what
the integration test covers
Andrew T.
http://ramblingsonrails.com
http://www.linkedin.com/in/andrewtimberlake
“I have never let my schooling interfere with my education” - Mark Twain
On Sat, Apr 18, 2009 at 8:18 AM, Ram [email protected] wrote:
way to go to become a better programmer (?)
I don’t think that this is a good idea at all.
Definitely start testing immediately but I wouldn’t rewrite the app at
all.
For every bug fix and change, make sure you write tests for the
functionality you are working on (in a TDD/BDD way - before changing
the code.)
Jim Wierich did an excellend talk at Scotland on Rails about Comment
Driven Development which, if I can summarise it accurately, is as
follows:
When changing/bug fixing existing code
If you do this whenever you work on existing code, you’ll grow the
test coverage of the app over time.
- use fixtures when I have to test something that uses complex
associations between models. especially when the alternative is to
spend a lot of time and brain on mocking/stubbing them instead. (I
have to mention I dont know the difference/similarities/functions of
mocking and stubbing completely)
I still wouldn’t use fixtures. I work with factories because then you
can put together the complex associations and data needed for just the
question at hand.
I have recently started creating a test library for very complex
applications that will build up a complex set of data via
TestData.load_data type calls. I do this so that I only load up the
data for those areas where the tests need them and not on every test.
- i dont have any client documentation to show for these tests. theyre
only for the sake of testing my code itself. So ill skip over RSpec
and Cucumber (until i feel a need for them)
Cucumber is not just for client documentation but does end-to-end or
full-stack testing which is useful for getting
as-close-as-the-client-experience testing
i am going to be adding features to the app in between too. anything I
have to keep in mind while doing that?
when do I start on integration and functional tests?
Also, any good articles that could help me gain some perspective on
the task i have ahead of me?
This I covered above. Start your testing with the new features
(Another reason not to re-write)
Include all the testing you want on a per-feature basis.
my 2 cents worth… i personally like the feel autotest gives.
especially for TDD. but hey… no experience. only tryouts and
screencasts.
I have no problem with autotest running on large projects as I find
that when it starts running the full suite, I’m busy writing the next
test/spec. When working with a failing test, autotest only re-runs the
failing test anyway.
Andrew T.
http://ramblingsonrails.com
http://www.linkedin.com/in/andrewtimberlake
“I have never let my schooling interfere with my education” - Mark Twain
Andrew T. wrote:
I don’t think that this is a good idea at all.
Definitely start testing immediately but I wouldn’t rewrite the app at all.
It ain’t a rewrite. Imagine if you could put a bookmark at one end of
all your
source. Above the bookmark is completely tested and below the bookmark
is
incidentally tested or not at all.
If you open a new project folder and start TDDing each feature, passing
each
test by copying code in, then what you are really doing is simply moving
that
bookmark down thru all your source until it hits the end.
If opening a new folder squicks you out, then comment out all the
code, and
TDD it to uncomment it. Either way, the resulting velocity is much
higher than
raw development.
For every bug fix and change, make sure you write tests for the
functionality you are working on (in a TDD/BDD way - before changing
the code.)
That is the advice from /Working Effectively with Legacy Code/ by Mike
Feathers.
On Sat, Apr 18, 2009 at 2:00 PM, Phlip [email protected] wrote:
If you open a new project folder and start TDDing each feature, passing each
That is the advice from /Working Effectively with Legacy Code/ by Mike Feathers.
I’m not advocating commenting out ALL the code, just the code around
the feature you’re working with.
When you’ve got an app with thousands of hours work, a rewrite is just
too huge.
What I’m suggesting is an iterative approach to eventually getting the
entire project covered based on the features you’re working with at
any given time.
Andrew T.
http://ramblingsonrails.com
http://www.linkedin.com/in/andrewtimberlake
“I have never let my schooling interfere with my education” - Mark Twain
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs