On Tue, Jun 21, 2011 at 8:37 AM, Colin Law <[email protected]> wrote:
> 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. 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? -- 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.
