I have a not-so-rails process that I’m developing in Rails.
The Rails part is all the admin/configuration stuff.
the non-so-Rails is what it actually does.
What it does is this:
submit a form to a website
wait for email report
remove attachments
do “stuff” with attachments
I’m trying to figure out how I can TEST something like this without
pounding
away on 100’s of web forms. They are “expensive” to generate and time
consuming to wait for them.
right now I’m doing the primate approach of running the entire thing
end-to-end and seeing what worked and what didn’t.
Also, along with this comes another question.
How do I write to logs for these not-so-Rails processes?
I’m trying to figure out how I can TEST something like this without pounding
away on 100’s of web forms. They are “expensive” to generate and time
consuming to wait for them.
Put all the clever stuff is in methods in models (mostly non
ActiveRecord models presumably) then your unit tests should be able to
test most of it using fake data without having to go off to the third
party website or wait for emails and so on. Then you just have to
check that the top level hangs together using a few end-to-end tests.
right now I’m doing the primate approach of running the entire thing
end-to-end and seeing what worked and what didn’t.
Also, along with this comes another question.
How do I write to logs for these not-so-Rails processes?
Essentially then the two steps of “looking for an email” and “dumping
the
attachements to files” can’t really be tested as part of any Unit level
testing. But I can run through the rest of the content.
Now that I think about it, I suppose I could do something like “look for
an
email” in a different directory and move it into the INBOX – then I can
test the applications execution of looking for an email and extracting
the
attachments. It’s a little bit of a hack - I’ll never really have a
100%
test until I hit these web sites.
I assume so, but I’m not sure where/how to introduce logging into my
modules which is consistent with the Rails framework.
I didn’t really want to create two sets of files for application
logging.
submit a form to a website
ActiveRecord models presumably) then your unit tests should be able to
test the applications execution of looking for an email and extracting
level tests to confirm that the whole system fits together.
I assume so, but I’m not sure where/how to introduce logging into my
modules
which is consistent with the Rails framework.
I didn’t really want to create two sets of files for application logging.
I meant that you can use the Rails logger to log messages to the
standard logs. See section 2.3 of Debugging Rails Applications — Ruby on Rails Guides
for how to do this. Also the rest of that guide is well worth
digesting, and all the other guides for that matter.
This is a great site and I’ll be spending some time with it.
I think part of the problem I have is that my application is a
“not-so-rails” in that it is:
run from ‘rails runner’ so I’m missing a lot of the Rails environment in
many objects that I have created.
I have 7 objects in /lib that are not ActiveRecord objects but use
ActiveRecord objects to update data.
The Rails Scaffold is largely there to provide a configuration
management
interface for this crontab command line process.
So I don’t have the Rails logger inherently in my code.
What approaches can I use to provide this logging into my command line
process libraries?
remove attachments
party website or wait for emails and so on. Then you just have to
check that the top level hangs together using a few end-to-end tests.
Essentially then the two steps of “looking for an email” and “dumping the
attachements to files” can’t really be tested as part of any Unit level
testing. But I can run through the rest of the content.
Now that I think about it, I suppose I could do something like “look for an
email” in a different directory and move it into the INBOX – then I can
test the applications execution of looking for an email and extracting the
attachments. It’s a little bit of a hack - I’ll never really have a 100%
test until I hit these web sites.
By splitting the task up into separate methods in the models you will
make it much easier to test and maintain. Your individual method
tests can concentrate on exercising that method, firing unusual
conditions at it and so on, to give you confidence that each method
does everything it is supposed to. This is not a hack, this is the
best way to do it. Then, as I said, you just need minimal integration
level tests to confirm that the whole system fits together.
I assume so, but I’m not sure where/how to introduce logging into my modules
which is consistent with the Rails framework.
I didn’t really want to create two sets of files for application logging.
I meant that you can use the Rails logger to log messages to the
standard logs. See section 2.3 of
for how to do this. Also the rest of that guide is well worth
digesting, and all the other guides for that matter.