Sbt tests

Últimamente en el trabajo estoy usando mucho delta para algunas tablas de dimensiones y estas tablas realizan actualizaciones parciales de las filas para replicar la lógica de negocio.

Esto, nos lleva a varios tests que replican un estado de la tabla y realizan las actualizaciones pertinentes para comprobar todos los flujos y por ende un sobrecoste de ejecución de ese tipo de tests que acaba siendo agotador.

Una de las soluciones planteadas fue incluir en las builds un parámetro para saltarse el step de ejecución de los tests. Lo cual es legítimo pero al menos para mí, resulta algo arbitrario. Buscando otro concens llegamos a: en las pull request se ejecutarán todos los tests y en el resto de builds (manuales o automáticas de rama) se excluirán estos tests, para que al hacer pruebas o durante las integraciones de las ramas no estemos acumulando tiempo en tests ya validados.

Me puse manos a la obra y desgrané el problema en dos:

1. Identificar que tests quiero ejecutar y lanzar solo estos.
2. Identificar que está triggeando la pipeline.

Identificar que tests quiero ejecutar

ScalaTest la verdad es que me ha dado la solución, aunque hay otras, para mi gusto la más cómoda son los tags.

Básicamente tenemos que crear un objeto que herede de la clase de tags:

import org.scalatest.Tag
import org.scalatest.flatspec.AnyFlatSpec
  
object MyTag extends Tag("MyTag")
  
class ExampleSpec extends AnyFlatSpec {

  it must "add correctly" in {
    val sum = 4 + 1
    assert(sum === 5)
  }
  
  it must "subtract correctly" taggedAs(MyTag) in {
    val diff = 4 - 1
    assert(diff === 3)
  }
}

Y ahora sbt nos permite usar estos comandos:

sbt testOnly -- -n "MyTag" // Con este test ejecutamos solo los tests que tengan el tag de MyTag, en este caso el test de “subtract correctly”

sbt testOnly -- -l "MyTag" // Con este test ejecutamos los tests que NO tengan el tag de MyTag en este caso el test de “add correctly”

Identificar que está triggeando la pipeline

En la mayoria de los sistemas de ci /cd hay variables predefinidas para esto: En Azure Devops por ejemplo tenemos la variable Build.Reason y en Github github.event.

Con esto podemos saber el contexto de nuestra build, adjunto un pequeño repo de github y un proyecto de prueba que enseña como funcionan las distintas partes:

https://github.com/adrianabreu/sbt-tests-filter

Si vamos a la parte de actions, podemos ver como para el push solo se lanza el test que no tiene el tag y como para la pull request, se lanzan todos :)