-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
Pensando en algunos ejercicios para explicar DDL, me topé con que los tipos de test que hay ahora son insuficientes para probar que la tabla esté bien creada. Tal vez las expectativas (ver #24) ayudarían.
Por el momento, se me ocurrió que podría hacer un mínimo chequeo de "que anda" insertando valores y luego haciendo una query. Para esto, vendría bien que el test de tipo query admita la posibilidad de ejecutar SQL después de la solución del/a estudiante; me lo imagino así:
type: query
after: |
INSERT INTO Evaluacion VALUES (1, 8.5, "¡Gran progreso! Te faltó terminar de entender el COUNT.", 15),
(2, 4, "Al filo de la desaprobación. Charlemos la clase que viene para que te pongas al día.", 3),
(3, 10, NULL, 7);
expected: SELECT * from Evaluacion;Con eso validaría en cierta medida, que la solución cree una tabla como esta:
CREATE TABLE Estudiante (
id int(10) NOT NULL PRIMARY KEY,
calificacion decimal DEFAULT NULL,
observacion varchar(255) DEFAULT NULL,
estudiante_id int NOT NULL
);Como hoy no existe la posibilidad, la hackeé un poco haciendo esto otro, que es incómodo por varias razones (hay que escribir los datos dos veces, se ven los INSERT en la web, etc):
type: final_dataset
final: |
INSERT INTO Evaluacion VALUES (1, 8.5, "¡Gran progreso! Te faltó terminar de entender el COUNT.", 15), (2, 4, "Al filo de la desaprobación. Charlemos la clase que viene para que te pongas al día.", 3), (3, 10, NULL, 7);
SELECT * FROM Evaluacion;
expected: |
id|calificacion|observacion|estudiante_id
1|8.5|¡Gran progreso! Te faltó terminar de entender el COUNT.|15
2|4|Al filo de la desaprobación. Charlemos la clase que viene para que te pongas al día.|3
3|10||7Metadata
Metadata
Assignees
Labels
No labels