Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Feature/analytics #210

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

Conversation

apardo
Copy link
Contributor

@apardo apardo commented Apr 13, 2016

Ya está terminado el tema de generar eventos en Google Analytics del ticket #111

@apardo
Copy link
Contributor Author

apardo commented Apr 13, 2016

Hay que meter un par de claves en secrets.yml de producción. Mirar el secrets.yml.example

@deivid-rodriguez
Copy link
Contributor

@apardo Buen trabajo. El primer comentario que se me ocurre es que los tests en realidad no están comprobando nuestro código, sino los internals de sidekiq (que seguro funcionan que ya los ha probado mucha gente). Apostaría que sí cambias todos los workers para que no hagan nada, en plan,

class AnalyticsCreateAdWorker
  include Sidekiq::Worker

  sidekiq_options queue: 'analytics_worker'

  def perform(ad_id)
  end
end

los tests seguirán pasando... :S

@deivid-rodriguez
Copy link
Contributor

@apardo Mira, para los tests yo veo dos opciones (no excluyentes, complementarias).

  • Por un lado, a nivel de controlador/integración. En este caso, la técnica que usan los tests actuales me parece adecuada. Lo único que queremos comprobar aquí es que cuando ocurren ciertos eventos en la app, "se hace algo de analytics". Entiendo que require 'sidekiq/testing' lo que hace es mockear #perform_async para que en vez de ejecutar el worker, simplemente lo ponga en una cola cuyo tamaño/contenido pueden comprobar los tests. Esta técnica de ver los workers como una caja negra va perfecta en este caso. Nos interesa simplemente añadir a los tests de integración asociados la comprobación de que el worker se pone en cola. No nos interesa lo que el worker hace, ni si lo hace bien, simplemente que se ejecuta.
  • Por otro lado, podemos añadir tests unitarios para comprobar que los workers son correctos. En ese caso, no necesitamos ningún mecanismo especial de sidekiq. Simplemente se trata de comprobar que el método #perform hace lo que tiene que hacer. Así que habría que hacer Worker.new.perform y correr comprobaciones sobre el resultado. En este caso, como lo que los workers hacen es simplemente llamar a una API externa, tendrías que usar webmock para mockear la llamada a la API y comprobar que se ejecuta con los parámetros correctos.

Espero que te sirva, cualquier cosa me dices.

@andreslucena
Copy link
Contributor

+1 a usar webmock para estas cosas (tests de conexiones con APIs externas)

@deivid-rodriguez deivid-rodriguez changed the title Feature/analytics [WIP] Feature/analytics Sep 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants