Pages Menu
Categories Menu

Posted by on Nov 25, 2016 in General | 1 comment

S.O.L.I.D. Principles, los necesitamos para testear bien (Parte 1/2)

– Post escrito por María Morales (@MaMoralesMC) y Noemí Navarro (@nnsanchez92).

En este post vamos a ampliar el conocimiento de los principios S.O.L.I.D. Ya se enumeraban en el blog en el año 2013 en este post. Te contamos brevemente sobre S.O.L.I.D, es un acrónimo creado por Tío Bob (Robert C. Martin, quizás le recuerdes de otros post del blog ya que se ha hablado de él en varias ocasiones) bajo el que se engloban cuatro principios que todo Diseño Orientado a Objetos debería seguir.

  • S (Single Responsability Principle) Es el Principio de Responsabilidad Única.
  • O (Open / Closed Principle) Es el Principio de Abierto Cerrado.
  • L (Liskov Substitution Principle) Es el Principio de Sustitución de Liskow.
  • I (Interface Segregation Principle) Es el Principio de Segregación de Interfaces.
  • D (Dependency Inversion Principle) Es el Principio de Inversión de Dependencias.

A continuación vamos a explicar cada uno de ellos, además vamos a ver la relación que tienen con el Testing (os dejamos también el enlace a los principios SOLID de Robert).

Single Responsibility Principle (SPR) – Principio de Responsabilidad Única

El principio SRP expone que una clase debería centrarse en hacer sólo una cosa, o tener una única responsabilidad. Esto no significa que deba tener sólo un método, tan sólo que todos los métodos deben estar centrados en un único objetivo, es decir, deben ser cohesivos.

Este principio está relacionado con la automatización de las pruebas, ya que si se incumple terminamos probando muchas clases que tienen dependencia entre sí (que esto también lo trataremos en el principio de inversión de dependencias), si por el contrario tenemos una sola clase con una sola responsabilidad probaremos de forma independiente.

A continuación os mostramos un dibujo de un diagrama UML donde se puede ver que rectángulo tiene varias responsabilidades y por tanto viola el principio de Responsabilidad Única.

captura-de-pantalla-2016-11-24-a-las-9-11-18

Más de una responsabilidad

Sin embargo en la siguiente imagen podemos ver las responsabilidades por separado, ya que aparece la entidad “Geometric Rectangle” con la función área.

Responsabilidades separadas

Responsabilidades separadas

Open Closed Principle (OCP) – Principio de Abierto/Cerrado

Bertrand Meyer puso el nombre a este principio (podéis leer más en este libro). El principio OCP explica de forma breve que las entidades (cuando hablamos de entidades nos referimos a clase, módulo, función, etc.) tienen que estar abiertas para poder ser extendidas, sin embargo tienen que estar cerradas para su modificación, es decir, el código fuente no se altere. Para seguir este principio se utiliza la abstracción.

El motivo por el cual se debe seguir este principio es que los cambios pueden influir negativamente en el código que funcionaba, entonces cuando aparecen funcionalidades nuevas se extiende el comportamiento de los módulos añadiendo código, pero no se cambia el código fuente que funciona ya que nadie está autorizado para ello.

Respecto al Testing, si para añadir código nuevo, hay que alterar el código que ya ha pasado el Testing Unitario, estamos en una mala práctica. A parte de pasar el Testing Unitario al código nuevo, tenemos que volver a lanzar las pruebas (lo que llamamos pruebas de regresión) y no deberán de fallar. De esta forma será más robusto porque no estamos cambiando el código ya probado.

Os dejamos un ejemplo explicativo de este principio. La primera imagen viola el principio de Abierto/Cerrado porque el cliente está ligado al servidor.

captura-de-pantalla-2016-11-24-a-las-9-15-37

Diseño que no se ajusta al principio abierto/cerrado

Sin embargo, la siguiente imagen muestra un diseño que sigue el principio de Abierto/ Cerrado porque utiliza la abstracción, de esta forma no se cambia el código.

Diseño que cumple el principio abierto/cerrado

Diseño que cumple el principio abierto/cerrado

Terminando…

Hasta aquí el post de hoy, lo hemos querido dividir en dos partes para que no sea demasiado largo. El viernes que viene publicaremos la segunda parte terminando así de explicar los principios S.O.L.I.D. restantes.

María Morales

María Morales

Practitioner at 233 Grados de TI
Interesada y apasionada en todo aquello que tenga relación con metodologías ágiles y calidad software, gestión de proyectos, modelos de procesos, DevOps y sobre todo en gestión de equipos.

Actualmente, colabora activamente con la Empresa y Comunidad 233, dando formación y mentoring ágil además de organizando eventos, charlas e iniciativas para difundir el conocimiento sobre Ingeniería del Software.

Profesionalmente dedicada al mentoring ágil en 233 Grados de TI, calidad software, testing ágil, a la implantación en importantes organizaciones de Scrum, agilidad, DevOps, Product Owner, peopleware, automatización de pruebas web y móviles con BDD, Calabash.

Certificada por la Scrum Manager como Scrum Manager con credenciales de profesora, entre otras certificaciones, como por ejemplo en GIT y GitHub.
María Morales

1 Comment

  1. Me parece muy bien la forma en que explica SOLID, felicidades y sigan publicando cosas como estas.

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This