[A02] Sobre los Inputs

[felipegarcia98]

Disculpen si lo mencionaron en clases, pero tengo la duda de cómo deberíamos considerar los inputs en la actividad.

Dado que se nos pasa un código que viene con parámetros definidos para la clase, pero la idea es testear la aplicación para los múltiples casos, y los casos se presentan prácticamente en un método, me suena sensato incorporar como inputs todos los valores que se ocupan, incluyendo los atributos de la clase y los parámetros de la función. Me equivoco? Y si así fuera, para casos en que se revise más funciones, se mantendría el mismo procedimiento por función?

Caso de ej:

class Clase
  attr_accessor :attr1, :attr2

  @@super_attr = "super_value"

  def initialize(
    attr1 = 0,
    attr2 = 1
  )
    @attr1= attr1
    @attr2 = attr2
  end

  def method1(attr3)
    if attr3 * @attr1 + @attr2 && @@super_attr == 'super_value'
      return 'muh'
    return 'beeh'
  end
end

Incorporaría algo tipo:
Input: attr1=123, attr2=321, attr3=1, super_attr='ah'
...

[rasaffie]

No estoy seguro si entendí bien tu pregunta, pero según lo que entendí la respuesta es sí: los atributos son otra forma de utilizar variables dentro de la lógica del programa, por lo que si afectan el comportamiento que se quiere probar, entonces también se deben considerar al diseñar pruebas. Otros ejemplos de input que podrían afectar al comportamiento son constantes de clases, lectura de archivos/DB o llamadas a servicios.

Por otro lado, puede ser que existan parámetros que no influyan en el código que se quiere probar, pero que de todas formas son necesarios para ejecutar las pruebas. Por ejemplo, tu clase Clase podría exigir un atributo adicional attr3 que si no se asigna levanta una excepción al inicializar la clase. Por ende, aunque no influya al momento de diseñar las pruebas para method1, de todas formas se le debería especificar un valor al implementar las pruebas, porque de lo contrario no se podrían ejecutar. Este valor podría ser siempre el mismo porque no afecta al resultado del método.

En este mismo sentido, contar con stubs facilita la configuración de pre-condiciones para código complejo. De esta forma la prueba se puede abstraer de la lógica adicional a lo que se quiere probar (como llamadas a servicios dentro del método), y configurar que devuelva los valores según lo que necesite cada prueba. El peligro de este enfoque es que se puede "falsear" más de la cuenta, lo que generaría que no se pruebe nada útil finalmente.