If you are not familiar with Query Cache, you only have to know that it's a very simple caching system from ActiveRecord that stores in memory all the queries performed during a request. If a query is fired more than one time, it will be in cache, so the database won't be affected.

The adventages of my approach are evident: you only use the database when some table has been modified or when a new query is executed. So you can get a notice an important speed improvement.

It is ideal for pages which have a lot of customization for the user logged in the application: in that cases it is very difficult to cache fragments or pages, because of the expiring of all that cache, and so many things.

Cache expiring

For expiring this cache, each Memcached key contains a sum of all the version numbers of the tables involved in the query. If one of that tables is modified, then the version number for that table is increased.

For example, the query below involves the table items and the table places:

So, the version for the cache of that query will be the sum of the cache version of the table items and the cache version of the table places.

Disclaimer

We are using this plugin in two on-line web projects: unvlog.com and iwannagothere, and everything seems to work fine (and faster than before), but these sites don't have so much traffic (about 30.000 req/day), so, there are stille possibilities that appear bugs and "unexpected behaviours".

In spite of all that, if you still are encouraged to try feel free to ask me anythin.

More information at README.

Cache test is a very useful plugin that allows you to test if action/fragment/page cache is generated or expired during a request. For me is very surprisingly that Rails hasn't asserts for testing the cache, specially when, if your application uses cache, it can be the cause of its malfunctioning. Apart of that cache is so tedious to debug.

The way it works is very easy:

     assert_cache_fragment({:fragment => 'total_posts'}) do
       get :index, :user_id => users(:first)
       assert_response :success
     end
 

In my plugin I have adapted the cache storage definition to Rails 2.x (moved to ActiveSupport, etc), added more asserts and some tests.

Enjoy it!

More info in the README.

The motivation was that I need it (of course), and there wasn't anything complete enough. So I found bb-ruby at GitHub and I decided to complete it with more tags, tests, and some stuff for doing it more flexible.

The result is a fork that you can find here:

http://github.com/ferblape/bb-ruby/tree/master

You can read the README file for getting more information.

If you want to add some special actions before and after the execution of each test, and don't want to add it to setup and teardown because you will be repeating your code for each unit test and functional test, or because it is a block, you can do an alias_method_chain for the run method:

 module Test
   module Unit
     class TestCase
       
 
       def run_with_my_block(*args, &block)
         Cache.clean # code before 
        
         a_block_that_you_want_to_execute do 
           run_without_my_block(*args, &block)
         end
         
         # Code after
       end
 
       alias_method_chain :run, :my_block
 
     end
   end
 end
 

You can redefine it at the beginning of your test_helper.rb for example.

Note that this code is only for Rails, becaus of the use of alias_method_chain function.

The problem is that it loads quite Javascript that has to connect to the main Google Maps page in order to draw our map. In order to avoid that we can use static Google Maps, it is, a picture (generated in real time) of the map we want to visualize. The problem with this is that you can't interact with the map (because it is an image) and that there is a limitation per day. But may be you find it useful in a particular moment.

For example, in iwannagothere.net we have a small map in every place that shows the location of that city:

In that situation we can change the map because the map is not for navigating along the city. For that you have a map in each item.

In Ruby on Rails, the programming framework of iwannagothere.net there is a gem called static-gmaps that does the hard work for you. What's more, we have found the way to integrate this maps with attachment_fu, in order you save a copy of the map in your filesystem and then avoid the day limitation usage.

Basically we have an attachment_fu kind of model (nothing special here):

class PlaceMap < ActiveRecord::Base
   belongs_to :place
 
   has_attachment  :content_type => :image, 
                   :storage => :file_system,
                   :processor=> :rmagick,
                   :path_prefix => 'public/userfiles/place_maps', 
                   :max_size => 1.megabyte
 
   validates_as_attachment  
 end
 

The we generate the static map instance:

	
 map = StaticGmaps::Map.new :center   => [ place.lat, place.long ],
                             :zoom     => 12,
                             :size     => [ 334, 144 ],
                             :key      => APP['gmkey']  
 

And save it in our PlaceMap model:

 PlaceMap.create(:uploaded_data => (open(map.url)), :place_id => place.id, :content_type => 'image/gif')
 

The problem here is that we are not uploading a file in the usual way: we are trying to save a raw of data. Attachment_fu doesn't know how to do that, so we have to apply a little patch:

 module Technoweenie
   module AttachmentFu
     module InstanceMethods
 
       def uploaded_data=(file_data)
         return nil if file_data.nil? || file_data.size == 0
         self.content_type = file_data.content_type
         self.filename     = Time.now.to_i.to_s+'.gif'
         if file_data.is_a?(StringIO)
           file_data.rewind
           self.temp_data = file_data.read
         else
           self.temp_path = file_data
         end
       end          
 
     end
   end
 end
 

Here we are giving a random filename, generated from the current time.

And that's all, really easy :)

iwannagothere.net is the last project from mamuso, Maria and me. It's a site about traveling with two main purposes:

1. share all the special places you have discovered in your travels: a singular monument, a delicious and cheap restaurant, a small museum with special charm, a park where you can see the most wonderful sunset ever...
2. help you to prepare your travels with all the information uploaded in the site

It's a kind of independent and high quality information travel guide.

As in unvlog.com we developed it in Ruby on Rails, (now running version 2.1), in our free time, along 3 months. Now we are refining a lot of details, and adapting some parts that we have seen people don't use as we thought.

We are going to explain all the technical issues we had in a serie of small posts in this blog or in the iwannagothere's blog. As well, we are going to present it at Spanish Rails Conference 08 in November.

We hope you enjoy the site and find it useful.

Un claro ejemplo lo encontramos cuando tenemos una relación :has_many y queremos comprobar si un elemento está incluída en dicha relación.

Por ejemplo:

 class Place < ActiveRecord::Base
   has_many :items
 end
 

 class Item < ActiveRecord::Base
   belongs_to :place
 end
 

Seguro que más de una vez, para comprobar que un place contiene un ítem hemos utilizado el "rubysta" include?:

 place.items.include?(item)
 

Pensándolo fríamente 0.2 segundos nos damos cuenta de que estamos cargando un array con todos los elementos de una relación, que pueden ser 10 o pueden ser 1.000.000. Y ya sabemos lo generoso que es Ruby con la memoria que toma y que nunca deja ir.

Un truco para evitar que esto suceda sin dejar de utilizar include? es definir dicho método dentro de la relación tal que así:

 class Place < ActiveRecord::Base
   has_many :items do 
     def include?(item)
       count(:conditions => ["item_id = ?", item.id]) > 0
     end
   end
 end
 

Es decir, resolvemos el problema con un simple COUNT de Mysql.

¿Alguien se anima a hacer un plugin? Creo que sería bastante inmediato para cuando se cumplen las convenciones y sabemos que la clave foránea de la relación es singular del nombre de la relación_id. O quizá ni eso, si encontramos la forma de preguntarle a ActiveRecord cuál es la clave foránea de una relación.

Sin embargo muchas veces con el log de Rails no es suficiente, y hay que alcanzar un mayor nivel de detalle.

El log en modo debug nos da todo el detalle que necesitamos, pero mostrando demasiada información (¿de qué nos sirve saber que un SELECT sencillo tarda 0.001 segundos?).

Pero si en ese log pudiéramos filtrar las consultas SQL más lentas sí que tendríamos información de consultas lentas asociadas a cada petición al servidor.

Gracias al plugin query trace y a una pequeña modificación podemos mostrar qué consultas tardan más de 1 segundo:

 module ActiveRecord
   module ConnectionAdapters
     class AbstractAdapter
       def log_info(sql, name, runtime)
         return unless @logger
         @logger.info(
           format_log_entry(
             "#{name.nil? ? "SQL" : name} (#{sprintf("%f", runtime)})",
             sql.gsub(/ +/, " ")
           )
         ) if (RAILS_ENV == 'production' && runtime > 1.0) || RAILS_ENV != 'production'
       end
     end
   end
 end
 

Este código lo he probado en Rails 1.2.x, no sé si funcionará en otras versiones.

Sin embargo yo utilizo un script que creo que me pasó porras para que me muestre en colores las modificaciones.

El script es este:

 #!/usr/bin/env ruby
 
 `svn diff #{ARGV.join(' ')}`.each do |line|
   puts( if line =~ /^\+(.*)$/
         "\e[32m#{$&}\e[0m"
         elsif line =~ /^-(.*)$/
           "\e[31m#{$&}\e[0m"
         else
           line
         end
       )
 end
 

Con darle permisos de ejecución ya podéis tener un svndiff por ejemplo.

No pongo el equivalente en git porque es bastante inmediato.

• claves: máximo de 250 caracteres
• valores alojados: máximo 1 Megabyte

Es muy difícil que una aplicación Rails las claves generadas a partir de las URL's tengan tanto tamaño, pero puede darse el caso y hay que tenerlo presente.

En el grupo de discusión acts_as_cached esta semana han propuesto hashear (con MD5, por ejemplo) las claves antes de guardarlas para curarnos en salud.

El problema es el siguiente: en unvlog.com (sí, ese proyecto del que no he hablado) somos muy Rails y tenemos para todos los recursos que tiene sentido una ruta que responde a un formato u otro según se le solicite pero con esta forma:

En concreto, esta URL corresponde al feed de un blog, feed que está cacheado en disco gracias a la caché de página de Rails. Pues bien, la idea es que el servidor web sirva directamente esta caché, así que una regla podría ser:

   if (-f /cache/$request_filename) {
           rewrite (.*) /cache/$1 break;
   }
 

(Esto, asumiendo que tenemos la caché en public/cache)

El problema es que esta regla no funciona, y creo que se debe a que blat.atom lleva un '.' y no es capaz de asignar la URL a la variable $request_filename.

Al final ha sido tan fácil como utilizar otra variable que he encontrado en la parte rusa del wiki, $request_uri:

   if (-f $document_root/cache/$request_uri) {
           rewrite ^/(.*).atom$ /cache/$1.atom break;
   }
 

Con esto ha funcionado perfectamente y ya tenemos cacheados y servidos por Nginx los feeds en unvlog.com.

Para acceder a él a través del cliente de Ruby, por ejemplo, basta con cargar una consola en el entorno deseado e invocar al método stats del objeto de caché.

Por ejemplo, si nuestra configuración es la siguiente:

   CACHE = MemCache.new 'localhost:11211', :namespace => 'wadus_fragments'
 

Podemos utilizar el objeto CACHE de la siguiente manera:

   pp CACHE.stats
   {"bytes"=>746532339,
    "pid"=>10303,
    "connection_structures"=>19,
    "time"=>1200349556,
    "limit_maxbytes"=>1073741824,
    "cmd_get"=>689486,
    "version"=>"1.1.12",
    "bytes_written"=>3296488315,
    "cmd_set"=>265986,
    "get_misses"=>265168,
    "total_connections"=>1238,
    "curr_connections"=>17,
    "curr_items"=>66977,
    "uptime"=>56490,
    "get_hits"=>424318,
    "total_items"=>265986,
    "rusage_system"=>95.012555,
    "rusage_user"=>17.16339,
    "bytes_read"=>3226552602}
 

La interpretación de todos estos valores se puede encontrar en la definición del protocolo:

   Name              Type     Meaning
   ----------------------------------
   pid               32u      Process id of this server process
   uptime            32u      Number of seconds this server has been running
   time              32u      current UNIX time according to the server
   version           string   Version string of this server
   pointer_size      32       Default size of pointers on the host OS
                              (generally 32 or 64)
   rusage_user       32u:32u  Accumulated user time for this process 
                              (seconds:microseconds)
   rusage_system     32u:32u  Accumulated system time for this process 
                              (seconds:microseconds)
   curr_items        32u      Current number of items stored by the server
   total_items       32u      Total number of items stored by this server 
                              ever since it started
   bytes             64u      Current number of bytes used by this server 
                              to store items
   curr_connections  32u      Number of open connections
   total_connections 32u      Total number of connections opened since 
                              the server started running
   connection_structures 32u  Number of connection structures allocated 
                              by the server
   cmd_get           64u      Cumulative number of retrieval requests
   cmd_set           64u      Cumulative number of storage requests
   get_hits          64u      Number of keys that have been requested and 
                              found present
   get_misses        64u      Number of items that have been requested 
                              and not found
   evictions         64u      Number of valid items removed from cache                                                                           
                              to free memory for new items                                                                                       
   bytes_read        64u      Total number of bytes read by this server 
                              from network
   bytes_written     64u      Total number of bytes sent by this server to 
                              network
   limit_maxbytes    32u      Number of bytes this server is allowed to
                              use for storage. 
   threads           32u      Number of worker threads requested.
                              (see doc/threads.txt)
 

En concreto cuatro parámetros me han parecido interesantes de observar:

• el parámetro bytes junto con el de limit_maxbytes: el primero representa el total de bytes ocupados actualmente, frente el máximo.
• el número de fallos de caché que refleja el valor del parámetro get_misses junto con el número de aciertos get_hits

Los primeros nos permiten saber si hemos llegado al límite el almacenamiento que necesita nuestra aplicación y el segundo nos permite saber si nuestra política de caché es adecuada: diviendo hits entre misses obtenemos la proporción de fragmentos encontrados frente a fragmentos que ya no existían. Un valor de 1 indica que por cada dos búsquedas, una tiene éxito y otra no.

Por supuesto un valor inferior a uno muestra que la caché no sirve de nada (indicaría por ejemplo que necesitaríamos ampliar el Memcache o que tenemos una política de borrado "exagerada").

Caché en Rails

Pronto, todas las demás, colgadas en la web de la Conferencia,

Además, en el post utilizan Nginx como servidor web y Ruby on Rails y Merb, como frameworks de desarrollo, así como Memcached para almacenar sesiones.

Los resultados, muy interesantes:

• Merb es mucho más rápido que Rails, a costa de perder parte de la magia
• Nginx es una gran alternativa a Apache, sobretodo cuando la memoria es un recurso escaso (en mi nuevo Slicehost, por ejemplo)
• y, el más importante, el evented Mongrel funciona bastante mejor que el Mongrel en situaciones de alta concurrencia

Así que si te gusta "jugar" y quieres probarlo, lo recomiendo: la instalación es muy sencilla y los resultados saltan a la vista.

La situación es la siguiente: es una cuenta Slicehost de 256Mb de memoria, en el que tú instalas lo que quieres. El problema es que debes de instalar un servidor web, los servidores de aplicaciones y la base de datos, y todos ellos han de luchar por esos 256Mb. Así que al final me he decidido por instalar esto:

• servidor web: Nginx, que tenía ganas de probarlo tras leer a uno de los sysadmins decir que Nginx era lo más estable que había visto nunca, y que recomendaba usar Apache sólo en el caso de querer que un mismo servidor web compartiera diferentes aplicaciones y en distintos lenguajes (PHP y Rails, por ejemplo). Además, su uso de memoria es ridículo.
• servidor de aplicaciones: Mongrel. Considerando los 60Mb que viene a consumir un Mongrel de memoria, el número de Mongrels en el clúster lo he establecido a 3.
• servidor de base de datos: MySQL. No había otra opción.

Además de todo esto, hay un servidor Memcached de 32Mb para guardar las sesiones.

Y claro, quería hacer pruebas de carga contra el stack completo para ver de rendimiento qué tal.

Las pruebas se han realizado contra una página sin caché y con bastantes consultas a la base de datos, cuyo tiempo de respuesta medio es de 0.005 segundos o lo que es lo mismo, unas 20 req/s.

El screencast

El screencast se queda algo corto en cuanto a uso de la herramienta httperf, ya que el autor pierde mucho tiempo explicando conceptos teóricos y muy básicos de Estadística: media y desviación estándar, así como cómo mostrar luego los resultados a través de gráficas (unas muy bonitas generadas con gruff).

Posteriormente las pruebas las realiza contra un único Mongrel, explicando con todo detalle:

• la importancia de utilizar datos reales: la muestra debe de ser representativa para que los resultados lo sean
• la importancia de obtener muchas muestras: cuantas más muestras, la media y la varianza son más significativas también
• la importancia de anotar todos los resultados
• la importancia de la interpretación de los mismos en función de los resultados obtenidos y entender qué significan

Las pruebas las realiza para comparar el rendimiento de su aplicación sin usar caché, utilizando caché de acción y utilizando caché de página. Así que establece el baseline en los resultados obtenidos sin utilizar caché y a partir de los obtenidos utilizando caché establece porcentajes de mejora.

Otros aspectos a tener en cuenta

Hay otras muchas situaciones en las que es recomendable hacer pruebas de rendimiento contra tu propia aplicación:

• calcular el número de Mongrels a lanzar en el servidor de aplicaciones. Una buena explicación (aunque breve también), la da Zed en la página de Mongrel: How many Mongrels
• comparar el rendimiento entre distintos sistemas de almacenamiento de sesiones
• comparar distintos algoritmos de balanceo en el módulo de proxy
• determinar el tope máximo de ficheros servidos a través de una unidad NFS
• ...

En estos casos es posible que nos interese conocer algún parámetro más de httperf que los que se han explicado en el vídeo:

• --rate: determinar el número de peticiones concurrentes lanzadas en un segundo
• --wsess: determina cada cuántas peticiones se inicia una nueva sesión

Y además, si vais a hacer pruebas de carga, hay que tener en cuenta estas perogrulladas, que a veces no lo son tanto:

1. el número de Mongrels en el clúster
2. la conexión: ¡no hagas las pruebas con un ADSL! En mi caso he pasado de 30 req/s a más de 50 req/s sólo por lanzar las pruebas desde una máquina con una conexión decente
3. testea el stack entero: sobre todo porque es interesante ver si hay problemas de conectividad entre una capa (web) y la otra (aplicación), o si el proxy que reparte la carga está mal configurado, etcétera

La verdad es que era un completo desconocido para mí hasta que encontré la presentación de Sergio Espeja en la conferencia de Rails: Tareas en background con RoR y BackgrounDRb.

En este año que ha pasado, hay una nueva versión que corrige algunos fallos y deja otros abiertos, pero que es, dicen, bastante estable. Y la verdad es que con la anterior tuve muchos problemas para crear mis workers pero con esta estoy encantado.

Pero este post no era para hablar de las bondades del proyecto, que son muchas, sino para contar cómo hacer que en los tests no necesitemos tener lanzado un servidor BackgroundDRB para que estos funcionen, sino que podemos utilizar un mock.

He encontrado uno entre los tickets del proyecto, y que se ve que aún no está incluído en la última versión.

Basta con descargarlo en test/mocks/test e incluir la siguiente línea en el test_helper.rb:

 require File.dirname(__FILE__) + '/mocks/test/backgroundrb_mock.rb'
 

Y voilá, tests funcionando de nuevo.

El plugin se llama helper_test y es muy sencillo de utilizar:

1. descargar
2. editar tests/test_helper.rb e incluír la línea: require File.expand_path(File.dirname(__FILE__) + '/helper_testcase')
3. utilizar el generador que incluye: ./script/generate helper_test Foo

El test generado tendrá este aspecto:

   require File.dirname(__FILE__) + '/../../test_helper'
 
   class FooHelperTest < HelperTestCase
 
     include FooHelper
 
     #fixtures :users, :articles
 
     def setup
       super
     end
 
   end
 

A destacar que podemos utilizar fixtures.

Y la forma de proceder también es muy sencilla: creamos un test y en su interior podemos invocar al helper como si de un método más se tratara y comparar el resultado obtenido con los valores esperados. Si el helper tiene argumentos, ampliaremos el abanico de pruebas.

Una pequeña reflexión

La verdad es que no he podido pensar mucho sobre la efectividad de este plugin ni tampoco tengo experiencia utilizándolo (de hecho los desarrolladores de The-Shaker estábamos algo preocupados sobre el vacío que teníamos en los helpers de la aplicación, pues no tienen tests). En principio y echando un pequeño vistazo a los helpers que tenemos, parece que sí que se van a poder testear todos utilizando este plugin.

Sin embargo, hay que notar dos cosas:

La primera es que si en tu helper has utilizado una variable de instancia (confiando en que en la vista donde vas a utilizar dicho helper, la variable ya esté instanciada y con valor), debes de asignar una variable de igual nombre antes de invocar al helper en el test. Por ejemplo:

 def available_tabs
   tabs =  "<ul>\n"
   tabs << " <li id=\"tab_blog\">" + link_to(_("Blog"), :controller => 'posts',
            :action => 'index', :blog_nicetitle => @blog.nicetitle) + "</li>\n"
   tabs << "</ul>\n"
 end

Y el test:

 def test_avaible_tabs
   @blog = blogs(:el_blog_de_quentin)
   tabs = available_tabs
   assert_equal tabs, '....'
 end

Y la segunda es más bien una sugerencia: muchas veces los helpers generan HTML, y todos sabemos lo coñazo que puede ser comprobar la estructura del mismo, y las bondades del assert_select. Pues bien, se puede hacer un hack no muy elegante, pero bastante práctico para poder utilizar assert_select con el valor obtenido por un helper. Basta con editar el fichero helper_testcase.rb e incluír la línea:

   @response   = ActionController::TestResponse.new
 

dentro de la función setup. Y ahora, con que asignemos el helper a @response.body ya lo tenemos. Veamos un ejemplo:

 def test_avaible_tabs
   @blog = blogs(:el_blog_de_quentin)
   @response.body = available_tabs
   assert_select 'ul'
 end

Es sucio, poco semántico, y muy DRY, porque lo tienes que asignar tras cada invocación al helper, pero parece que de momento no hay otra forma. ¿Alguien se atreve a redefinir?

Su uso es bastante sencillo y cumple su labor perfectamente, a excepción de pequeños detalles que parece que falten por pulir.

Uno de esos "detalles insignificantes" es, para mi humilde opinión, el testing, que, aunque se puede realizar sin problemas, y con una cobertura muy buena de la funcionalidad, no queda tan limpio como queda en otras partes del framework.

De hecho, una de las cosas que más se echa en falta es algo de documentación. Por suerte, en los Manuales de Rails (qué mal suena, ¿no?), encontramos un "libro" sobre testing en Rails, y uno de sus capítulos es testing your Mailers, que es justo lo que queremos hacer.

Ahí proponen un esquema o esqueleto para los tests de unidad tal que así:

 require File.dirname(__FILE__) + '/../test_helper'
 require 'my_mailer'
 
 
 class MyMailerTest < Test::Unit::TestCase
   fixtures :users
   FIXTURES_PATH = File.dirname(__FILE__) + '/../fixtures'
   CHARSET = "utf-8" 
 
   include ActionMailer::Quoting
 
   def setup
     ActionMailer::Base.delivery_method = :test
     ActionMailer::Base.perform_deliveries = true
     ActionMailer::Base.deliveries = []
 
     @expected = TMail::Mail.new
     @expected.set_content_type "text", "plain", { "charset" => CHARSET }
   end
 
   def test_reset_password
     user = User.find(:first)
     newpass = 'newpass'
     response = MyMailer.create_reset_password(user,newpass)
     assert_equal 'Your New Password', response.subject
     assert_match /Dear #{user.full_name},/, response.body
     assert_match /New Password: #{newpass}/, response.body
     assert_equal user.email, response.to[0]
   end
 
   private
     def read_fixture(action)
       IO.readlines("#{FIXTURES_PATH}/community_mailer/#{action}")
     end
 
     def encode(subject)
       quoted_printable(subject, CHARSET)
     end
 end
 

Así un poco por encima, además de los requires pertinentes y de establecer unas cuantas constantes debemos de incluír include ActionMailer::Quoting para poder utilizarlo en los tests con aquellos emails que tengan acentos, eñes o cualquier otro carácter no estándar en el subject.

En el método setup configuramos el ActionMailer y además creamos un objeto TMail llamado @expected, y que utilizaremos en todos los tests para compararlo con el que genera nuestro modelo:

   def setup
     ActionMailer::Base.delivery_method = :test
     ActionMailer::Base.perform_deliveries = true
     ActionMailer::Base.deliveries = []
 
     @expected = TMail::Mail.new
     @expected.set_content_type "text", "plain", { "charset" => CHARSET }
   end
 

Y respecto a las fixturas, básicamente no tenemos, así que nos proponen utilizar ficheros de texto plano cuyo contenido será el contenido del email. Esos ficheros se sitúan en RAIlS_ROOT/test/fixtures/community_mailer/ como se puede ver en la función read_fixture:

   def read_fixture(action)
     IO.readlines("#{FIXTURES_PATH}/community_mailer/#{action}")
   end
 

Nuestro propio test

Con el esquema ya creado podemos empezar a escribir nuestros propios tests sobre nuestros modelos de Mailer.

Por ejemplo, veamos una acción muy simple de La Coctelera, que te envía un email cada vez que alguien te añade como amigo:

 	def new_friend(user,friend)
     @headers['reply-to'] = user.email
     @from = 'admin@domain.com'
     @recipients = friend.email
     @subject = "[La Coctelera] #{user.shortname} te ha añadido como amigo"
     @body = {
       'user_name' => user.name,
       'friend_name' => friend.name,
       'profile_link' => profile_url(user.username),
       'profile_link_friends' => friends_url(friend.username)
     }
   end
 

Y esta es la vista asociada:

 Hola <%= @friend_name %>!
 
 <%= @user_name %> te ha añadido como amig@. Puedes visitar su página en la siguiente
 dirección: <%= @profile_link %>
 
 Puedes ver a todos tus amigos en:
 
 <%= @profile_link_friends %>
 
 Hasta otra!
 
 --
 La Coctelera
 http://www.lacoctelera.com
 

El test podría ser algo tal que así:

 def test_new_friend
   user = User.find_by_username('lucas')
   friend = User.find_by_username('blat')
   @expected.from = APP['adminmaster']
   @expected.subject = encode("[La Coctelera] #{user.shortname} te ha añadido como amigo")
   @expected.body = read_fixture('new_friend')
   @expected.to = friend.email
   @expected.reply_to = user.email
   assert_equal @expected.encoded, Notifier.create_new_friend(user, friend).encoded
 end
 

El procedimiento es muy sencillo:

• cargamos a los dos usuarios implicados en la acción
• vamos rellenando los atributos de @expected con los valores que esperamos que tenga el email resultante: remitente, asunto, contenido, destinatario...
• finalmente, comparamos el email "esperado", con el que genera la acción create_new_friend

Hemos necesitado crear una fixtura new_friend con el siguiente contenido:

 Hola Fernando!
 
 Lucas Nicolás te ha añadido como amig@. Puedes visitar su página en la siguiente dirección: http://test.host/lucas/perfil
 
 Puedes ver a todos tus amigos en:
 
 http://test.host/blat/amigos
 
 Hasta otra!
 
 --
 La Coctelera
 http://test.host
 

Como veis, esta fixtura tiene una limitación más que evidente: no es dinámica, y su contenido depende de los valores (en este caso de los usuarios), que estamos utilizando en el test.

También quiero destacar esta línea:

   @expected.subject = encode("[La Coctelera] #{user.shortname} te ha añadido como amigo")
 

Cuando el subject del email vaya a incluir algún caracter acentuado, o con eñe, como es el caso, hay que forzar la recodificación de la cadena, pues ActionMailer también la recodificará cuando cree el email.

En un post posterior propondremos un par de mejoras para solventar alguna de las deficiencias que hemos visto.

Supongo que todo es acostumbrarse a utilizar uno u otro.