Un test no es más que una función de Business Central creada dentro de una codeunit de test y con un decorador que indica explícitamente que se trata de un test.
codeunit 50100 “My Development – Test”
{
Subtype = Test;
[Test]
procedure MyDevelopmentTest001()
begin
end;
}
🔵 Las secciones de un test
Pero, ¿qué código tengo que escribir dentro de este procedimiento?
Un test debería contener una explicación del escenario que se quiere probar y después tres secciones de código claramente diferenciadas:
- Creación de los datos necesarios para el test
- Ejecución del código a probar
- Comprobación del resultado
Son el DADO-CUANDO-ENTONCES, o en inglés GIVEN-WHEN-THEN. En lenguaje natural vendría a decir: DADOS unos ciertos datos, CUANDO se realiza una cierta acción, ENTONCES se tiene que producir un cierto resultado.
Imaginemos que nos han encargado la tarea de crear un nuevo campo en las líneas de venta que el usuario rellenará manualmente al crear un pedido, y nos han pedido que la información de este campo en el pedido de venta tiene que estar presente en el albarán de venta cuando se registre el envío del pedido.
Para poder probar este escenario, diríamos: DADO un cliente, un pedido de venta para ese cliente e información en el nuevo campo creado en la línea de venta, CUANDO registramos el envío del pedido, ENTONCES la información del nuevo campo en la línea de venta se ha trasladado a un campo con el mismo nombre en la línea de albarán.
Trasladando esto a nuestra función de test, de momento tendríamos el siguiente código:
[Test]
procedure FieldNuevoCampoIsFilledInSalesShipments()
begin
// [SCENARIO] El campo “Nuevo Campo” de la línea de venta se traslada
// a un campo con el mismo nombre en las líneas de albarán cuando
// registramos el documento de venta
// [GIVEN] Un pedido de venta con una línea
// Información en el campo “Nuevo Campo” de la línea
// [WHEN] Registramos el envío del pedido de venta
// [THEN] El albarán creado contiene la misma información en el
// campo “Nuevo Campo”
end;
De momento hemos escrito sólo comentarios, pero fijaros que:
- Hemos definido claramente el escenario tanto en el nombre de la función de test como en una sección de escenario
- Hemos definido los datos previos que necesitamos para el test. El objetivo es registrar un albarán de venta y ver que tiene los datos adecuados, de modo que necesitamos un pedido de venta con al menos una línea
- Hemos definido cuál es el código a evaluar: el proceso de registro de un documento de venta
- Hemos definido cuál es la comprobación a realiza
🔵 El código de un test
Ahora es el momento de empezar a escribir código en cada una de estas secciones. Para ello, crearemos algunas variables y haremos uso de algunas funciones auxiliares que encontraremos en las extensiones del framework de test de Business Central.
Creación de datos
En la sección GIVEN necesitamos crear un pedido. Para ello, utilizaremos algunas funciones auxiliares que encontramos en una codeunit llamada “Library – Sales”, definida en la extensión “Tests – TestLibraries”.
[Test]
procedure FieldNuevoCampoIsFilledInSalesShipments()
var
SalesHeader: Record “Sales Header”;
SalesLine: Record “Sales Line”;
LibrarySales: Codeunit “Library – Sales”;
begin
// [SCENARIO] El campo “Nuevo Campo” de la línea de venta se traslada
// a un campo con el mismo nombre en las líneas de albarán cuando
// registramos el documento de venta
// [GIVEN] Un pedido de venta con una línea
// Información en el campo “Nuevo Campo” de la línea
LibrarySales.CreateSalesHeader(SalesHeader, “Sales Document Type”::Order, ”);
LibrarySales.CreateSalesLine(SalesLine, SalesHeader, “Sales Line Type”::Item, ”, 1);
SalesLine.Validate(“Nuevo Campo”, ‘Información en el campo’);
SalesLine.Modify();
// [WHEN] Registramos el envío del pedido de venta
// [THEN] El albarán creado contiene la misma información en el
// campo “Nuevo Campo”
end;
Lo primero que hacemos es llamar a la función CreateSalesHeader(), a la que le pasamos por referencia una variable de la tabla “Sales Header”, le indicamos qué tipo de documento queremos crear y especificamos para qué cliente es el pedido (en este caso, no le pasamos ningún cliente en particular y la función CreateSalesHeader() se encargará de crear uno nuevo). Con esto, ya tenemos un documento de venta creado.
Después creamos una línea para ese pedido llamando a la función CreateSalesLine() y pasándole por referencia variables de las tablas “Sales Header” y “Sales Line”, además de indicar que queremos crear una línea de tipo producto, para ningún producto en particular (la función se encargará de crear un producto nuevo), y con Cantidad 1.
Finalmente, ponemos un dato cualquiera en el campo “Nuevo Campo” y guardamos el cambio en base de datos.
Para tener tests bien definidos, que no dependan del entorno y que puedan ejecutarse en cualquier base de datos de Business Central es super importante que el propio test cree absolutamente todos los datos que necesita.
Para crear un pedido de venta necesitamos un cliente. No podemos depender de clientes ya existentes en la Base de Datos. ¿Qué pasa si en la empresa donde vamos a ejecutar los tests no hay clientes? ¿O si están todos bloqueados? ¿O no tienen la configuración contable adecuada? En este caso el test fallaría no porque la funcionalidad que hemos desarrollado nosotros tenga algún bug, sino porqué no podemos asignar ningún cliente al pedido. Es por eso que si inspeccionamos paso a paso la función CreateSalesHeader() veremos que si no tiene cliente, se crea uno al que le asigna una forma y término de pago cualquiera (si no encuentra ninguna adecuada la crea), y unos grupos contables cualquieras (si no encuentra ningunos adecuados los crea).
Lo mismo pasa en la función CreateSalesLine(), que crea un producto nuevo al que le asigna una Unidad de Medida Base cualquiera (si no encuentra ninguna adecuada la crea), y unos grupos contables cualquieras (si no encuentra ningunos adecuados los crea).
▶ Ejecución del código a probar
La sección WHEN debería ser la más corta de todas. No más de una o dos líneas de código que ejecutan la funcionalidad que hemos desarrollado y estamos probando.
En este caso, el código a probar está dentro del proceso de registro de un albarán de venta de Business Central, de modo que lo que tenemos que hacer es registrar el documento. Para ello, utilizaremos de nuevo algunas de las funciones auxiliares de la codeunit “Library – Sales”.
// [WHEN] Registramos el envío del pedido de venta
DocumentNo := LibrarySales.PostSalesDocument(SalesHeader, true, false);
Llamamos a la función PostSalesDocument() pasándole el documento de venta que queremos registrar e indicando que queremos registrar el albarán y que no queremos registrar la factura. Esta función nos devolverá el Nº de documento registrado, en este caso el Nº de albarán, que capturamos en una variable local llamada DocumentNo que creamos en la propia función de test.
▶ Las comprobaciones
Finalmente, en la sección THEN haremos las comprobaciones necesarias para asegurar no sólo que el código se ha ejecutado sin errores, sino además que ha hecho lo que se supone que tenía que hacer.
En nuestro caso, queremos comprobar que la información que el usuario introduzca en el campo “Nuevo Campo” de las líneas de venta se traslade al campo del mismo nombre en las líneas del albarán.
Para ello, deberemos buscar el albarán en la base de datos (por eso nos hemos guardado el Nº de documento) y comprobar qué valor tiene.
// [THEN] El albarán creado contiene la misma información en el
// campo “Nuevo Campo”
SalesShipmentLine.SetRange(“Document No.”, DocumentNo);
SalesShipmentLine.SetRange(“Line No.”, SalesLine.“Line No.”);
SalesShipmentLine.FindFirst();
Assert.AreEqual(SalesLine.”Nuevo Campo”, SalesShipmentLine.“Nuevo Campo”, ‘Valor incorrecto’);
Con las tres primeras líneas leemos de base de datos la línea de albarán que se acaba de registrar y que se corresponde con la línea de venta con la que estamos trabajando.
En la última línea es donde hacemos las comprobaciones. Definimos una variable llamada Assert de la codeunit Assert, y ejecutamos una función llamada AreEqual() al que le tenemos que pasar el valor que esperamos, el que realmente hay, y un mensaje que se mostrará sólo en caso que la comprobación falle.
▶ El test al completo
Así es como ha quedado nuestra función de test. Ahora ya está preparada para ser ejecutada y ver el resultado.
[Test]
procedure FieldNuevoCampoIsFilledInSalesShipments()
var
SalesHeader: Record “Sales Header”;
SalesLine: Record “Sales Line”;
SalesShipmentLine: Record “Sales Shipment Line”;
LibrarySales: Codeunit “Library – Sales”;
Assert: Codeunit Assert;
DocumentNo: Code[20];
begin
// [SCENARIO] El campo “Nuevo Campo” de la línea de venta se traslada
// a un campo con el mismo nombre en las líneas de albarán cuando
// registramos el documento de venta
// [GIVEN] Un pedido de venta con una línea
// Información en el campo “Nuevo Campo” de la línea
LibrarySales.CreateSalesHeader(SalesHeader, “Sales Document Type”::Order, ”);
LibrarySales.CreateSalesLine(SalesLine, SalesHeader, “Sales Line Type”::Item, ”, 1);
SalesLine.Validate(“Nuevo Campo”, ‘Información en el campo’);
SalesLine.Modify();
// [WHEN] Registramos el envío del pedido de venta
DocumentNo := LibrarySales.PostSalesDocument(SalesHeader, true, false);
// [THEN] El albarán creado contiene la misma información en el
// campo “Nuevo Campo”
SalesShipmentLine.SetRange(“Document No.”, DocumentNo);
SalesShipmentLine.SetRange(“Line No.”, SalesLine.“Line No.”);
SalesShipmentLine.FindFirst();
Assert.AreEqual(SalesLine.“Nuevo Campo”, SalesShipmentLine.“Nuevo Campo”, ‘Valor incorrecto’);
end;
El resultado, si la implementación de la funcionalidad real está bien desarrollada, debería ser satisfactorio.
🔵 Keep learning TDD with ClipPlatform
Aquí tienes algunos recursos para aprender TDD con ClipPlatform:
- La Masterclass gratuita “Testing con TDD”, que tendrá lugar el próximo miércoles 15 de febrero a las 15.30h. Apúntate aquí.
- El “Curso Testing con TDD” , disponible en nuestra plataforma
- Los posts “Testing automatizado en proyectos de Business Central” y “La experiencia de ClipPlatform aplicando Testing”
Comentarios