Hola Iñigo,

Gracias por tus comentarios.

Igual no he leído bien el código, pero me parece que no depende del documento de venta. Lo que hace que se tomen los datos de una tabla u otra es que el valor que se valida sobre campo “Ship-To Code”. Si es ”copia los datos de envío de la tabla dirección de envío, en otro caso se copian diréctamente del cliente.

No no, aquí quien no leyó bien el código fui yo. Hay alguna condición que si que parece que depende del tipo de documento, pero después en realidad vi que en las devoluciones y abonos, se estaba utilizando la información de dirección de la “Información Empresa”. Y seguramente si hubiera utilizado un almacén, la dirección hubiera sido la del almacén.
De modo que estaba completamente equivocada en lo que dije en esa parte de la lección.

Por otro lado, en la función que rellena/completa la tabla de dirección de envío, entiendo que los campos que hay que validar es porque tienen código en su correspondiente trigger de tabla. ¿Es necesario en estos casos crear su registro correspondiente en la tabla a la que apuntan, como por ejemplo cuando creas un C.P. antes de validarlo?. ¿Sería válido también olvidarse de las validaciones y rellenar los campos mediante asignaciones (:=), con lo cual no hay que estar pendiente de crear registros en tablas relacionadas?

Si, para hacer el test podrías rellenar la información mediante asignaciones en lugar de mediante validaciones.
Yo lo hice así porque – me parece que lo comento en algún momento en el curso – he creado eso función CreateShipToAddress a semejanza de una que encontré en la codeunit de test Library – Sales.
Pero vamos, que para el propósito de este test, asignaciones nos hubieran bastado.

Un saludo,
Cristina Nicolàs

Hola Iñigo,

Eso ya depende.
Cuando hacemos un desarrollo y lo testeamos, entiendo que nos interesan 2 cosas: que nuestro desarrollo funciona, pero también que no nos hemos cargado cosas del estándar.

En el caso de ejemplo del curso, en los documentos de venta Oferta, Pedido, Pedido Abierto y Factura, nos interesa comprobar que los documentos tienen la información que el desarrollo le ha metido (la información que viene de la tabla de dirección de envío).

En el caso de Devolución y Abono, vimos que el estándar de Navision no se comportaba del mismo modo, y que nuestro desarrollo no aplicaba.
En el curso, lo que hago es comprobar que en estos casos la información es la que provee el propio estándar de Navision (que en el ejemplo, después de dar algunas vueltas, acaba siendo la información que viene de la Información Empresa).
Pero podria haber hecho otra cosa.
En lugar de comprobar que la información es la correcta, podría haber simplemente comprobado que la información no es la mia, que es otra, no se que otra, pero otra.

Es decir, en lugar de hacer comprobaciones tipo AreEqual(), podria haber hecho comprobaciones tipo AreNotEqual().

En cualquier caso, en estos casos en los que no aplica mi funcionalidad, también podría haber hecho mucho menos test o incluso no hacer test en absoluto.
Porque aunque he dicho que me interesa saber que mi desarrollo funciona y que no rompe nada del estándar, la verdad es que tampoco me pondré a escribir tests de toooodo el estándar de NAV para comprobar que sigue funcionando!

En fin, que va un poco a gusto de cada uno hasta donde se llega con los tests.

Un saludo,
Cristina Nicolàs