Desarrollo ágil
Tests unitarios
✓ TODO
□ ¿Los milestones
internos son productos mínimamente viables?
□ ¿Se han integrado
tareas en el gestor?
Recordatorio: Se comprueban
comportamientos
Reflejados en las
historias de usuario
Sin las HUs es un caos. Si es "no
sé quién me dijo" que, acaban apareciendo las costuras por
algún lado". No se hacen productos coherentes, ni productos
que el equipo pueda sacar adelante
Los tests se ejecutan desde
frameworks de test
En muchos casos son
indistinguibles de la biblioteca de
aserciones, pero en muchos lenguajes, como
JavaScript, están aparte.
Principios F.I.R.S.T
Fast, independent, repeatable,
self-validating, timely
Red/green/refactor
Lo importante son los
tests
Es decir, lo de hacerlos primero no
hace falta que se lleve a cabo. Y lo de "timely" y "fast"
muchas veces no depende del marco o de los tests en sí, sino
del framework
Tests en Elixir (con
mix
)
defmodule IssueTest do
use ExUnit.Case
doctest Issue
setup_all do
this_issue = %Issue{ projectname: 'Foo', id: '1'}
{:ok, issue: this_issue}
end
test "Initial issue state",context do
assert context[:issue].state == :Open
end
end
Arrange , act ,
assert
Corresponde a cada uno de los
tests, a lo que se va a hacer en cada paso.
TypeScript con jest
import { Issue, State } from '../Project/Issue';
var data: Issue;
beforeAll(() => {
data = new Issue("Foo",1);
});
test("all", () => {
expect( data.show_state() ).toBe( State.Open );
data.close();
expect( data.show_state() ).toBe( State.Closed );
});
Arrange sería el
beforeAll; es similar al setup del que hemos hablado antes (y desde luego
parecidísimo a una fixture), lo que
ocurre es que jest permite que se hagan precondiciones antes de
cualquier test, y también antes y después de cada una de las
instrucciones de test que se
ejecuten
Go es su propio marco de test
package HitosIV
import (
"testing"
"reflect"
)
func TestHitos (t *testing.T){
t.Log("Test Id");
if CuantosHitos() <= 0 {
t.Error("No milestones")
}
}
func TestTodosHitos (t *testing.T){
t.Log("Test Todos");
these_milestones := Hitos()
if reflect.TypeOf(these_milestones).String() == "Data" {
t.Error("No milestones here")
}
}
En realidad el segundo se
puede eliminar, porque estamos testeando el setup. Sirva como
ilustración, de todas formas.
Hooks para tests locales
my $is_head = `git rev-parse --verify HEAD`;
my $last_commit = $is_head?"HEAD":"4b825dc642cb6eb9a060e54bf8d69288fbee4904";
my @changes = `git diff-index --name-only $last_commit`;
my %policies = ( no_underscore => qr/_/ );
for my $f (@changes) {
for my $p ( keys %policies ) {
if ($f =~ /$policies{$p}/) {
die "[FORMATO]: $p ";
}
}
}
Para que los ficheros
sigan una serie de políticas de nombres, en Perl
en este caso. Por supuesto, se trataría de
crear esos hooks para poder pasar tests, linters o
cualquier otra cosa que hiciera falta,
localmente. Muchos van a ir más en la categoría de
código limpio o respetar estándares, pero se puede
ejecutar cualquier cosa. Y, por supuesto, forma la
base de los sistemas de CI/CD que se verán a continuación.
✓ TODO hito 12
Elegir marco de test +
añadir test
a tareas
En
agil.yaml
testing:
runner: make
framework: prove