Testing y Test Unitarios

[VictorCasajuana]

Hola, alguien está haciendo Testing en Fivewin?

A Raíz del vídeo de Manuel Calero de la 2ª Conferencia de Harbour : https://medium.com/harbour-magazine/videos-de-la-2%C2%AA-conferencia-de-harbour-magazine-89552811ab34 que explica como realizar test unitarios en Harbour, me puse a Indagar y después de hablar con Manuel me descargué su repositorio de HB_Unit https://github.com/manuelcalerosolis/hbunit con su permiso.

Me puse a investigar sobre el testing (que era un terreno totalmente nuevo para mí) y descubrí unas herramientas fantásticas para dar una estabilidad y red de protección a mis clases y programas.

He realizado algunas mejoras y ampliaciones sobre el hb_unit y estoy implementando los test unitarios en cualquier clase nueva que hago y si refactorizo antiguas también (en la medida de lo posible), a nivel de seguridad es un antes y un después, sobre todo a la hora de refactorizar y añadir nuevas características.

Pongo este post aquí por si alguien más está interesado en el Testing en HB o ya lo está haciendo para unificar criterios y esfuerzos mejorando hb_unit y así tener una clase para test unitarios potente. Sé que hay otras clases en Harbour para test unitarios pero esta me pareció la más completa y parecida al resto de clases de tests que se utilizan en otros lenguajes de programación.

Un Saludo!

[José Luis Sánchez]

Hola Victor,
yo estoy interesado en el tema, por favor ponte en contacto conmigo en el correo de Harbour Magazine o utilizando el formulario de contecto de alanit.com

Saludos,
José Luis

[VictorCasajuana]

Hola Victor,
yo estoy interesado en el tema, por favor ponte en contacto conmigo en el correo de Harbour Magazine o utilizando el formulario de contecto de alanit.com

Saludos,
José Luis

José Luis, enviado.

[xmanuel]

Creo que sería buena idea que publiques tus avances por aquí...

[VictorCasajuana]

Claro.

Aquí está el repositorio para hacer testing con algunas ampliaciones que he incluido para testear resultados tipo Array:
https://github.com/VictorCasajuanaMas/hbunit
Se puede mejorar la representación de los resultados, ya que al principio parece algo engorrosa, pero cuando te pones a utilizarlo, ves que es más que suficiente para encontrar el fallo y solucionarlo.



Aquí está el enlace al post de Harbour Magazine donde Manuel Calero explica con mucha maestría como funciona, con una parte inicial muy buena para los que no han echo nunca testing.

Le tema del testing (al menos el que yo tuve) es que al principio no se le ve mucho sentido y parece tiempo perdido, pero es una inversión con un retorno del 100% en tiempo a la hora de tocar código existente.

El resto es incluir tests a discreción ( sin llegar a lo absurdo ) para tener una buena red de seguridad en nuestro software. Aquí un ejemplo de un test que me "testea" el cálculo de una factura de cliente con IVA

Code: Select all  Expand view

METHOD Test_FacCli_3IVA_RE_Ret_2Dto() CLASS Test_TDocumentoCalcula

    Local oFaccCab
    Local oFaccLin

    ::oCliente:SetDefaultData()
    ::oCliente:RECARGO := .T.
    ::oCliente:IRPF    := 15

    WITH OBJECT oFaccCab := TFaccCab():NewWithOutRelation()
        :CODCLI  := 1
        :DTOPOR1 := 10
        :DTOPOR2 := 7
    END

    WITH OBJECT oFaccLin := TFaccLin():NewWithOutRelation()
        aAdD( :aDataLoad, TFaccLin():NewWithOutRelation() )
        aAdD( :aDataLoad, TFaccLin():NewWithOutRelation() )
        aAdD( :aDataLoad, TFaccLin():NewWithOutRelation() )
    END
    oFaccLin:GoTop()
    DocLinAsignaDatos( oFaccCab, oFaccLin, 'V21', 21, 21, 1, 100 )

    oFaccLin:Skip()
    DocLinAsignaDatos( oFaccCab, oFaccLin, 'V10', 10, 10, 1, 100 )

    oFaccLin:Skip()
    DocLinAsignaDatos( oFaccCab, oFaccLin, 'V4', 4, 4, 1, 100 )

    WITH OBJECT TDocumentoCalcula():New()
        :ocTLin       :=  oFaccLin
        :oCabecera    :=  oFaccCab
        :oCliente     :=  ::oCliente
        :oArticulos   :=  ::oArticulos
        :nSerie       :=  1
        :oQueDoc      :=  TQueDoc():New( DOC_FACCLI )
        :cDivisa      :=  oFaccCab:DIVISA

        :Calcula()
    END

    ::Assert():equals( 248.68, oFaccCab:TOTAL, 'Test Factura Cliente con recargo de equivalencia, Retención, 2 Descuento 3 Artículos al 21%, 10% y 4%')

Return ( Nil )
 

Realmente la línea del test propiamente dicha y que hace las comprobaciones del resultado es la última:

Code: Select all  Expand view

::Assert():equals( 248.68, oFaccCab:TOTAL, 'Test Factura Cliente con recargo de equivalencia, Retención, 2 Descuento 3 Artículos al 21%, 10% y 4%')

Ventajas? te aseguras que cualquier cambio que hagas en la función que te calcula el total de una factura, te va a funcionar con este caso de uso, de lo contrario, antes de meterte en producción te salta el fallo y puedes solucionarlo.

[hmpaquito]

Víctor,

Muy interesante. Me tengo que repasar ese artículo que mencionas.

Yo por mi parte una de las cosas que hago para mejor debuguear es: En cada clase creo un metodo ::Debug() que lleva las principales datas de la clase y otras relaciones y las devuelvo como cadena y que puedo imprimir en cada momento.
Ademas en cada clase tengo una DATA llamada cCreacionDesde que contiene las procnames donde se creo el objeto.

Luego en el errorsys, cuando se vuelcan las variables, si la clase tiene el metodo ::Debug() lo muestro

Saludos

[VictorCasajuana]

Interesante sistema para recolectar más información de los errores. Tomo nota!

Yo tengo un API montada y cuando un programa saca un error, me envía una petición al API con toda la info del error en formato Json y así puedo analizarla y corregir rápidamente los errores. Cuando el cliente me contacta, ya tengo toda la info del error para poder darle solución más rápido

El testing es diferente ya que lo que se intenta es evitar los errores o al menos minimizarlos al máximo.