On 21 June 2011 13:21, Tom Allison <[email protected]> wrote: > On Sat, Jun 18, 2011 at 5:13 AM, Colin Law <[email protected]> wrote: >> >> On 18 June 2011 10:04, Tom Allison <[email protected]> wrote: >> > 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. >> >> 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. > > 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. >> >> > >> > 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? >> >> Can't you use the logger in the normal way? >> > 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 http://guides.rubyonrails.org/debugging_rails_applications.html for how to do this. Also the rest of that guide is well worth digesting, and all the other guides for that matter. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
