Functional Testing for Attachment-fu

I found a lot of good tutorials on how to setup attachment_fu (which lets you easily store images or other binary data in a Rails app, either in the filesystem or in the database itself), but none of them explain how to write proper functional tests. Since a lot of other people have been posting this question, I thought I would post what I just got working:

def test_should_create_new_attachment

fdata = fixture_file_upload('/files/photo1.jpg', 'image/jpeg')

login_as :bob

assert_difference Photo, :count, 2 do
post :create, :photo => { :uploaded_data => fdata }, :html => { :multipart => true }
end

assert_redirected_to user_url(users(:bob))
assert_valid assigns(:photo)

end

The above assumes you create a 'files' directory inside of your fixtures directory. Also note that if you have thumbnailing enabled, each file you upload will create multiple attachment objects (in this case, one to represent the original image and one to represent a thumbnail).

If you're curious, here's how I have the plugin configured:

class Photo < ActiveRecord::Base

has_attachment :content_type => :image,
:storage => :file_system,
:max_size => 500.kilobytes,
:resize_to => '320x200>',
:thumbnails => { :thumb => '100x100>' },
:processor => 'ImageScience'

validates_as_attachment


end

Rcov is awesome but not without these tweaks

I've recently started using the rails_rcov plugin to test how well I am testing the code I am writing. It's been a great help, but I was getting very strange results until I read this post about how to configure rcov properly to concentrate its testing. (Basically you have to force it to run your unit and functional tests in isolation which seems counterintuitive). It's easy enough to add parameters to your rakefile that will straighten it out.

Now I am going to try to get Heckle working for even better testing of my tests.

Notes from Mark Chalfant and Molly Woods

We had a great workshop from Mark Chalfant and Molly Woods of WIT where we asked them to teach us the key ingredients of what makes improv good. Below are the notes that I took.

• What makes improv good?
  
  
  
  • Believability
  • Playfulness
  • Fearlessness
  
  
• Helpful Exercises
  
  
  • Cosby warmup: we all did short two-person scenes where everyone had to do their worst Bill Cosby impression. You could do this with any impression, the point of it was to get everyone used to taking risks and embracing failure.
  
  
  • Two person scenes, focusing on whether players kept whatever big choice they started with
  
  
  • Do a scene that is not funny but is realistic: focus on believability. Other players sit in audience and raise their hand when they see something that is not believable. Then pause the action to ask players what was not believable. [as when Nick Johne had us do a similar exercise, these scenes actually became incredibly funny]
  
  
• Audience enjoys great emotional commitment/interplay, not clever text or circumstances. Without emotional interchange, we have nothing but people being clever. This can work but you can't rely on being clever every night because that will fail you.


• Characters can ask each other to give up things or to leave, but each character has to fight for what's important to them -- you can't just give in right away.


• To move a scene forward/get yourself out trouble, ask yourself "What behavior have I created, and how can I create more?"


• At the top of scenes, each player "takes out a toy" (each 'choice' is a toy). You should play with each toy as much as possible before you throw it out. Find a way to embrace that first choice -- you don't have to 100% logically understand your choice, and you definitely don't have to explain everything to the audience, as long as there are real human emotions. Audience wants to recognize themselves on stage -- "I've been that guy or that girl" -- no matter the circumstance.


• Improvise in "the of course": assume as much as possible about your circumstances. Don't be polite or "check-in" with others.


• Let information in the scene go through you, change your character.
  


• On stage, we don't want to solve problems, we want to heighten them.


• Pop culture references are fine, but we need them to resonate with the scene. Don't just play clever games with your references.


• At its best, improv combines the whackiness of improvisation with the emotional commitment of theater leads.


• It's always easy to find conflict, so no need to frontload it. Explore other things in your scene, and if conflict doesn't emerge organically, you can always find it later.


• Good Challenges:
  
  
  
  • Start every sentence with "I" or "you"
  
  
  • Ask each player to state in one or two sentence what defines their character's viewpoint. Then only allow them to use those lines for dialogue for the rest of the scene.
  
  
  • Only use emotional noises, no text or words (shows that you don't have to advance the plot all the time, can have a good scene just by being emotional)
  
  

Build a Toy First

So far in my career I've only developed web applications for internal use -- intranet sites and the like. Recently I gave myself the challenge to create a simple public web app over the course of the weekend. Writing the code took only the weekend, but getting the deployment configuration right, and optimizing to withstand just the small trickle of traffic I was seeing took two more weeks.

I thought I knew Rails and Apache and MySQL and other technologies inside and out, but once I had to really cope with real-world obstacles I was knocked on my ass. My original configuration was not fast enough, and I had to implement caching to make things more responsive. I set up a number of monitoring systems to automatically restart my dispatchers if something went wrong. I found an awesome SSH client for my Treo which I had to use when my server started acting up and I was away from my home computer.

I also learned that the Internet is international -- I unconsciously assumed that most of my users would be based in the United States, but that's exactly wrong. I've got users from Växjö to Santiago de Compostela.

The site itself isn't much to look at -- I'm no graphic designer -- but it represents a major lesson for me in how to deploy a public-facing site. I'm greatly influenced by it while pursuing my other projects -- for instance, I now bake caching considerations directly into my code. I am not relying on flash[:notice] to pass messages back to the user. I'm either creating separate notification pages that can be cached, or I'm using Ajax to just update small parts of the page with status messages.