Reducción del nivel de conectividad utilizando DI para mejorar la capacidad de prueba del código, ejemplo de implementación

Al comienzo del artículo quiero señalar de inmediato que no pretendo ser nuevo, sino que solo quiero compartir / recordar una oportunidad como IoC DI.

Además, casi no tengo experiencia escribiendo artículos, este es el primero. Hice mi mejor esfuerzo, si no juzgas estrictamente.

De que estamos hablando

La mayoría de los proyectos de Rails con los que me he encontrado tienen un gran problema. O bien no tienen pruebas en absoluto, o sus pruebas verifican alguna parte insignificante, mientras que la calidad de estas pruebas deja mucho que desear.

La razón principal de esto es que el desarrollador simplemente no sabe cómo escribir el código, por lo que en las pruebas unitarias solo prueba el código escrito por él y no prueba el código, que, por ejemplo, está contenido en algún otro objeto de servicio o biblioteca.

Además, se forma una cadena lógica en la cabeza del programador, pero por qué necesito transferir el código de lógica de negocios a otra capa, agregaré aquí solo un par de líneas y todo cumplirá con los requisitos del cliente.

Y esto es muy malo, porque las pruebas unitarias pierden su resistencia a la refactorización y la gestión de los cambios en dicho código se vuelve difícil. La entropía está aumentando gradualmente. Y si ya tiene miedo de refactorizar su código, las cosas están muy mal.

Para resolver estos problemas en el mundo de Java, existen varias bibliotecas desde hace mucho tiempo y no hay una razón particular para reinventar la rueda, aunque debe tenerse en cuenta que estas soluciones son muy engorrosas y no siempre hay una razón para usarlas. Los rubististas parecen resolver de alguna manera tales problemas de una manera diferente, pero honestamente, todavía no entendía cómo. Por lo tanto, decidí compartir cómo decidí hacerlo.

La idea general de cómo resolver esto en proyectos ruby

La idea básica es que para los objetos que tienen dependencias, deberíamos poder administrarlos.

Considere un ejemplo:

class UserService def initialize() @notification_service = NotificationService.new end def block_user(user) user.block! @notification_service.send(user, 'you have been blocked') end end 

Para probar el método block_user, nos encontramos en un momento desagradable, porque notificar desde NotificationService funcionará para nosotros y nos vemos obligados a procesar una parte mínima que realiza este método.
La inversión nos permite simplemente salir de esta situación si implementamos un servicio de usuario, por ejemplo, así:

 class UserService def initialize(notification_service = NotificationService.new) @notification_service = notification_service end def block_user(user) user.block! @notification_service.send(user, 'you have been blocked') end end 

Ahora, al probar, pasamos un objeto como simulación NotificationService, y verificamos que block_user extraiga los métodos de notify_service en el orden correcto y con los argumentos correctos.

 RSpec.describe UserService, type: :service do let (:notification_service) { instance_double(NotificationService) } let (:service) { UserService.new(notification_service) } describe ".block_user" do let (:user) { instance_double(User) } it "should block user and send notification" do expect(user).to receive :block! expect(notification_service).to receive(:send).with(user, "you have been blocked") service.block_user(user) end end end 

Estudio de caso para rieles

Cuando hay muchos objetos de servicio en el sistema, se hace difícil construir todas las dependencias usted mismo, el código comienza a crecer con líneas de código adicionales que reducen la legibilidad.

En este sentido, se me ocurrió escribir un pequeño módulo que automatiza la gestión de dependencias.

 module Services module Injector def self.included(base) # TODO: check base, should be controller or service base.extend ClassMethods end module ClassMethods def inject_service(name) service = Services::Helpers::Service.new(name) attr_writer service.to_s define_method service.to_s do instance_variable_get("@#{service.to_s}").tap { |s| return s if s } instance_variable_set("@#{service.to_s}", service.instance) end end end end module Helpers class Service def initialize(name) raise ArgumentError, 'name of service should be a Symbol' unless name.is_a? Symbol @name = name.to_s.downcase @class = "#{@name.camelcase}Service".constantize unless @class.respond_to? :instance raise ArgumentError, "#{@name.to_s} should be singleton (respond to instance method)" end end def to_s "#{@name}_service" end def instance if Rails.env.test? if defined? RSpec::Mocks::ExampleMethods extend RSpec::Mocks::ExampleMethods instance_double @class else nil end else @class.instance end end end end end 

Hay una advertencia, el servicio debe ser Singleton, es decir tener un método de instancia. La forma más fácil de hacerlo es escribiendo include Singleton en la clase de servicio.

Ahora en el ApplicationController agrega

 require 'services' class ApplicationController < ActionController::Base include Services::Injector end 

Y ahora en los controladores podemos hacer esto

 class WelcomeController < ApplicationController inject_service :welcome def index render plain: welcome_service.text end end 

En la especificación de este controlador, obtenemos automáticamente instancia_doble (WelcomeService) como dependencia.

 RSpec.describe WelcomeController, type: :controller do describe "index" do it "should render text from test service" do allow(controller.welcome_service).to receive(:text).and_return "OK" get :index expect(response).to have_attributes body: "OK" expect(response).to have_http_status 200 end end end 

¿Qué se puede mejorar?

Imagine, por ejemplo, que en nuestro sistema hay varias opciones sobre cómo podemos enviar notificaciones, por ejemplo, en la noche será un proveedor y otro durante el día. Al mismo tiempo, los proveedores tienen protocolos de envío completamente diferentes.

En general, la interfaz NotificationService sigue siendo la misma, pero hay dos implementaciones específicas.

 class NightlyNotificationService < NotificationService end class DailyNotificationService < NotificationService end 

Ahora podemos escribir una clase que realizará un mapeo condicional de servicios

 class NotificationServiceMapper include Singleton def take now = Time.now ((now.hour >= 00) and (now.hour <= 8)) ? NightlyNotificationService : DailyNotificationService end end 

Ahora, cuando tomamos la instancia de servicio en Services :: Helpers :: Service.instance, necesitamos verificar si hay un objeto * Mapper, y si es así, tomar la clase constante a través de take.