Crear una mejor experiencia para el usuario: Guia del Logo para Windows
No hay nada mas frustrante que cuando estas con el computador y todo sale mal.
La experiencia del usuario es la combinacion del Hardware + Sistema Operativo + Resto del software. Muchas veces se le hecha la culpa a los 2 primeros pero de forma frequente el problema real esta en el ultimo.
Son incontables las veces que frente a un problema con el computador la solución haya sido “Reformatear el equipo” debido a que el software en cuestion hace algo mal hecho.
Como desarrolladores tenemos la responsabilidad de hacer aplicaciones funcionales y que no frusten a la gente. Solo que muchas veces desconocemos que existen guias & buenas practicas a seguir para tal fin.
Estas operan bajo el umbral del “Windows Logo Program” que es una certificacion que da Microsoft a los productores de software (es cuando encontramos esas etiquetas que dicen “Certificado para Windows Vista” & similares) que delinea buenas practicas a seguir. Aunque la certificacion oficial tiene un coste elevado, nada impide el seguir las pautas que se delinean.
Entre ellas se encuentran:
- Forma correcta de instalar aplicaciones que funcionen sin permisos de administrador y no muestren el molesto aviso del UAC en Vista
- Como hacer apliaciones que operen de forma segura
El documento se puede descargar de aquí.
0 comments | 0 pingbacks | tags: delphi, programacion, windows
Como ser un programador contratable…
Aunque parezca que estoy con un trauma creativo con la poca actualización de este blog, la verdad es que…si, es asi. No! Realmente trabajando duro y conversando con la gente de los foros de www.clubdelphi.com . Esta conversación si fue bien interesante, trata sobre como aumentar las probabilidades de ser contratado en una empresa de software, asi que denle una mirada.
0 comments | 0 pingbacks | tags: programacion
Muchos creen que el mundo de software es solamente complicado por su código, ese montón de 0 y 1 o esa cantidad de líneas en un lenguaje de programación concreto.
Luego, a la hora de implementar o usar el software se descubre que es complicado por su uso, porque falla, porque no instala, porque se vuelve obsoleto, porque llueve y porque hace sol también.
Pero no termina allí. Es notoria la confusión en cuanto al licenciamiento, uso y distribución del software.
Por lo general se tiene la mentalidad de que:
Todo software comercial es costoso, monopolista y cerrado
y
Todo software “open source” es abierto, gratis y libre
Al igual que un programa típico esta compuesto de diferentes partes, la parte económica y social del mismo también. Suponiendo un software que se va a distribuir, por cualquier razón, un programa completo consta de:
Un(os) autor(es)
Bueno, todo código al final tiene uno o varios autores, quienes diseñan y programan el sistema. Por defecto, todo el material del programa le(s) pertenece(n) exclusivamente por la leyes internacionales de derechos de autor, a menos que de alguna manera hayan dado un paso al respecto.
Código fuente
Todo programa requiere código fuente, las instrucciones que se escriben en un mas-o-menos-comprensible-para-humanos lenguaje de computador. Este es el indispensable para poder corregir y mejorar el programa.
Código compilado
Otro programa se encarga de “compilar” o convertir ese código fuente en un sistema binario que pueda ser ejecutado por la máquina.
Archivos anexos
Como pueden ser los archivos de ayuda, imagenes y demás.
Licencia
El cual es el contrato de uso del programa.
Si un programa no tiene una licencia explicita, es difícil saber que hacer al respecto (como no soy abogado, no tengo idea, y la idea que tengo, me la guardo para que luego no me llame de la carcel alguien quejandose de mi consejo).
Por eso, si Ud. es un desarrollador y no especifica una licencia, por favor hagalo.
Una licencia ES UN CONTRATO. Es por eso que es tan complicado como cualquier otro contrato, y para muchos, incomprensible. Como muchos contratos, pocos lo leen y menos lo entienden, pero como también muchos atestiguaran, puede volverse en contra y patearnos en el hígado.
Por eso, es indispensable buscar asesoría legal al respecto. ¿La razón? Los abogados saben de problemas legales, incluso problemas que uno como programador o usuario NI SE IMAGINA.
Como desarrollador, AUN SI SE ELIGE UNA LICENCIA OPEN SOURCE, es una señal de responsabilidad revisar el mismo por un abogado, en especial si el software o sitio web o lo que sea va a tener distribución significativa o va a ser usado bajo serias condiciones (por ejemplo, al manejar dinero). ¿La razón? Las leyes varían de país en país y además — y es posible que las cláusulas de una licencia copiada de internet sean ILEGALES en el país.
¿Cuales? No se. Yo no soy abogado, ningún desarrollador sin experiencia legal esta capacitado para saber en que rayos se esta metiendo, de igual manera que un abogado sin experiencia en desarrollo podrá entender porque solo hay 10 tipos de personas en este mundo: Los que entienden binario y los que no (-i.e. si quedo en blanco es un chiste de programadores-).
Sistema de distribución
O sea, como se hace llegar al usuario final. Puede ser copiando archivos, imprimiendo el código en papel, descargando de un sitio, obteniendo el archivo binario, o el código fuente.
Al final se reduce en el “open source” que contrario a la creencia popular, nada tiene que ver con hippies que promulgan la libertad y el anti-monopolio, ni mucho menos significa “gratis”.
“Open source” significa “Código abierto” o sea, que se distribuye el programa en sus archivos fuentes para su posterior compilación, que es algo útil en manos de un programador y puede-que-si-o-no útil para el resto de la gente.
Y esta el “binary” (o: “código binario”) que no significa, como muchos creen, que las libertades de la gente estan negadas, que es monopolista y demás chorradas.
Solo quiere decir que el código esta “cerrado” porque el software esta compilado en archivos binarios, y por lo tanto a menos que seas un operador de la matrix, no entenderás todos esos caracteres raros.
Es por eso que al final todos los programas “open source” se transforman en “binary” de forma natural. SIN LA LICENCIA, no se puede presumir absolutamente nada acerca de lo que “open” y “closed” significa.
Un modelo económico
Entiendase por el mismo, como el mecanismo de integración al mundo real.
Puede ser por medio de pagar el diseño, el desarrollo, la entrega, la distribución, la capacitación, o puede ser pagando por todo o por ninguno de los anteriores (en economía, sea como sea, se “paga” el tiempo en emplear algo, en saber usarlo, en costos indirectos como la luz y el agua, etc… por eso es que no hay nada absolutamente gratuito).
Puede que haya una motivación intelectual, espiritual, monetaria, o similar, o todo junto u otras. El modelo económico no esta directamente ligado al software. Es por eso que hay software “cerrado” o “closed” que sale más barato que el “abierto” y al revés también.
Al final, el dueño del software debe mezclar todos los elementos para traducir un aburrido programa de computador en un producto, o sea, en algo que se puede usar, entender, distribuir y desechar. Asi que al final, es importante de parte y parte entender cuales son las motivaciones ecónomicas del programa y bajo que contrato (licencia) se da derecho al uso del mismo.
O puede que darle “siguiente siguiente” sirva también hasta que llegue la policia ;).
0 comments | 0 pingbacks | tags: delphi, open source, programacion, software
Grupo de usuarios Delphi/Afines Medellín / Colombia
Ya es hora de que los programadores de Delphi / Pascal / C# / C++ y afines usando tecnologia de Borland tengamos apoyo en Medellín.
Estoy armando un grupo de usuarios. Más info: http://www.clubdelphi.com/foros/showthread.php?p=160321#post160321.
0 comments | 0 pingbacks | tags: delphi, programacion
Ya se público mi segundo artículo: Programando al programador en el sitio de desarrolladores de CodeGear.
Trata sobre lo que es minimamente necesario para trabajar de forma organizada.
0 comments | 0 pingbacks | tags: delphi, programacion
Se publico mi primer artículo en CDN (CodeGear Developer Network) : Codificar para el cambio.
Es algo que escribi hace dos años, cuando era mas joven pero igual de feo. Espero les guste!.
0 comments | 0 pingbacks | tags: delphi, programacion
Ok, ahora vamos a hacer nuestro primer “servicio” o aplicacion multi/nivel. Pero antes que vayamos a programar como locos, es bueno prepararse un poco, mental y tecnicamente. Evitando trampas comunes.
La teoría dice:
Separa la interfaz de usuario de la lógica de negocios del acceso a datos
Pero la práctica se encarga de arruinarlo. Por ejemplo, si empezamos a hacer un sistema de contabilidad uno imagina inmediatamente los formularios de edición, los combos, las grillas (grids), etc… Entonces la mayoría hace la parte gráfica y luego va armando el servidor en base a ella.
Mal hecho, chico. Ahora el “servicio” depende de la parte gráfica (asi sea conceptualmente), y luego no portará bien a otro tipo de cliente (como un cliente web o uno celular). Ahora bien, lo más probable es que la cosa no sea tan extrema como para soportar celulares, el construir a base de la GUI genera un monton de problemas de diseño, y le quita flexibilidad.
Para poder separar el servidor del cliente, debemos PRECINDIR del cliente… o mejor dicho, de la representación gráfica del mismo. Una manera práctica es crear un “cliente” que sea la ventana de comandos de DOS (tipo Consola) o mucho mejor: Usar DUnit. Con DUnit, podemos hacer aplicaciones que hacen pruebas automatizadamente y a la vez, es un excelente cliente que nos permitira probar nuestro servidor sin amarrarlo a la interfaz gráfica.
Un asunto con la programación Cliente/Servidor es que la programación del Cliente es mucho más RAD pero la del servidor requiere más trabajo de código y no es tanto la parte de pegar componentes o controles.
Adicionalmente, al forzarnos a trabajar en código causa que mejoremos el diseño de la interfaze del servidor. Aunque parezca increible, muchas veces el tener que escribir el código y OBLIGAR a probarlo empieza a generar un efecto interesante: No me gusta escribir tanto código! Y como se vuelve un poco aburridor, obliga simplificar, reorganizar, reconstruir las clases hasta que hacen lo que tienen que hacer de la forma más práctica posible…
En la práctica, muchas veces se observa que de forma rutinaria en múltiples lugares se llama un proceso y se repiten varias líneas de código con ligeros cambios o parametros, el hacer un cliente con DUnit obliga a evadir ese código y a expresarlo de forma sencilla.Otra trampa común que se ve alentada por lo “simple” de generar un demo ejecutable en minutos es evadir las especificaciones, diseño y todo eso.
De paso, es la forma más segura de agregarle unos cuantos meses (o años) a un desarrollo de por cierto complicado, con más dolores de cabeza y más noches sin dormir. Asi, que mejor en este tipo de aplicaciones es hacer POR LO MENOS las especificaciones. Me gusta este artículo que da sugerencias muy prácticas y que de hecho estamos implementando en mi empresa El malabarista y se siente la mejora.
Pa’ afuera, no pa’ dentro
La mayoria de los programadores programa pa’dentro (empiezan por modelar los datos — como tablas y campos, vistas, etc… -) luego le meten el “alambre” que conecta a los datos y luego hacen los formularios. Luego las validaciones de entrada y por fin la lógica de negocios. Entonces quizás los reportes, el instalador, etc… ¿La razón? es que es MUY fácil hacerlo asi.
El problema es que pronto estará “hackeando” el código de lógica de negocios, para que se ADAPTE a los formularios, validaciones, campos, tablas, vistas y base de datos.
El punto es, el código de la base de datos, las tablas, los controles, etc… eso ya esta HECHO. Ya sea si usa Sql Server o Firebird o Paradox, el motor de base de datos ya sabe que hacer. Delphi tiene una excelente libreria, la VCL, y sabe que hacer. Lo UNICO que esta en DUDA es la lógica de la aplicación, el resto es carpinteria.
Programar pa’dentro es construir una casa asi: Se pavimenta la calle, se montan las paredes y el techo, se hace la parte de alambrado electrico y demás de las paredes, se pone los tomas de corriente, agua, gas, se cava hondo, se pone la tuberia interna, se cava mas, se ponen los cimientos. Ups! una roca estorbo la tuberia, toco cambiarla de puesto e interfiere con esa columna… rayos! eso desetabiliza el techo, reformemos el techo, No! el muro frontal hay que moverlo tan solo 1 centimetro!. Evidentemente, esta es una forma muy entretenidad de hacer casas. Y asi se entretienen la mayoria de los programadores, porque programa pa’dentro.
Es por eso que el orden lógico es: Lógica de negocios — Acceso a datos — Interface gráfica — Interface de Informes — Base de datos o sistema de almacenamiento — Todo lo demás.
O sea, como es una casa: Cimientos, tuberias, paredes, techo, pavimento. Pintura y acabado, perfecto!
El asunto es simple: El acceso a datos, la interface gráfica, los informes y la base de datos debe girar ALREDEDOR de la lógica de negocios y no al revez. Una vez que las clases y la funcionalidad interna estan estabilizadas, estas dictan de forma natural el diseño de la base de datos… incluso el acceso a datos se vera mucho más “limpio” y las consultas serán más simples. Conectar a la interface gráfica sera mucho más sencillo (en parte: La lógica de negocios tendra en si misma la mayor parte de las validaciones) y los informes seran más faciles de sacar (ya que la base de datos esta correctamente modelada a partir del modelo conceptual del programa!).
Va a sonar algo extraño que primero esta el “Acceso a datos” pero de ultimo esta “Base de datos” con mucho pasos intermedios. La razón? Es simple, el acceso a datos se deberia mantener en memoria!Esa es una de las grandes ventajas de usar pruebas automatizadas. Es MUY complejo armar una prueba automatizada sobre bases de datos reales (toca recrear la base de datos y llenar con datos de prueba para obtener pruebas repetibles!) y como al principio se va a hacer cambios importantes, no aguanta! asi que lo mas sencillo de hacer es modelar las clases de forma tal que puedan manejar datos en memoria.
Eso no significa necesariamente que hay que renunciar a los TDataSet. De hecho, no hay razon para hacerlo. Simplemente se pueden crear DataSet en memoria (con TClientDataSet), llenar los campos y datos de prueba, que normalmente son muy pocos.Eso es asi al menos al principio.
Obviamente al ir conectando las partes se llegara a un punto en donde el modelo de la base de datos se vera de forma evidente, y se injecta en el proyecto. Aqui metemos las pruebas de desempeño y simulación de cargas y demas cosas. El orden de desarrollo no es estrictamente sequencial, mas bien es un trabajo en paralelo. Evidentemente habra que hacer ajustes aqui y alla, pero si DEMORAMOS lo mas posible el meter todo lo que NO ES logica de negocios, el numero de cambios se reducira ampliamente.
Al programar pa’afuera, nos aseguramos de tener un cimiento solido sobre el cual construir. Eso en terminos de POO creara una alta cohesion y deberia bajar inter-dependencia (coupling) de las clases, que en términos generales es lo mejor.
Asi que recuerde: Programar pa’afuera (primero los cimientos, entonces lo demas) no solo hara a un sistema en cuanto a su codigo mas sano y solido, sino que tambien ayuda a un desarrollo más rápido y flexible!
0 comments | 0 pingbacks | tags: delphi, programacion
Click.. click.. tap.. RUN.. CRASH!!! Un mejor RAD!
La mayor debilidad se encuentra en su fortaleza
Y eso en cierto de la programación RAD. Click.. click.. tap.. RUN! y !presto! una aplicación de base de datos completa con interfaz de usuario y edición de datos en minutos, gracias al poder de Delphi.
Click.. click.. tap.. RUN.. CRASH!!! es el resultado de programar una aplicación real al estilo de los tutoriales que muestran como se conectan los controles… como si realmente enseñaran arquitectura…
El diseño del acceso a datos en Delphi es el MEJOR equilibrado que he visto en todas las herramientas de desarrollo que he manejado (Visual FoxPro, Visual basic (aqui ni habia un diseño), Java, .NET). Aunque cada herramienta/plataforma tiene puntos muy fuertes (por ejemplo, en .NET es más simple hacer un acceso a datos válido para un ambiente Web) la arquitectura de datos (el combo de TDatabase/TDataSource/TDataSet) permite:
- Una interfaz sencilla para navegar datos… Next, Prior, First, Last. Funciones de búsqueda simples como Locate y sofisticadas como Filter.
- Una forma simple de editar. Edit, Post, Add. Hermoso.
- Un enlace a los controles que no apesta, como en Visual Basic. Con buen desempeño, visual (incluso se ven los datos en tiempo de diseño) que se puede “desconectar” temporalmente para soportar algún proceso y que simplemente, es tan bueno que no hay que hacerle nada más.
- Lo más importante: En lo que respecta a los controles, solo entienden una clase abstracta (TDataSource) y se puede intercambiar entre diversas versiones de TDataSet que conectan con distintas tecnologias como BDE, ADO, ODBC, Acceso directo o bases de datos como Sql Server, Firebird, Oracle, Acces… Asi que al contrarior que en otras herramientas no hay que alterar la interfaz grafica ni hacerle ningún código especial cuando se cambia la tecnologia que accede a los datos (algo desagradablemente común).
Lo que la mayoria de nosotros no captamos es que la arquitectura de Delphi SEPARA el acceso a datos de la interfaz gráfica y de como se conectan AMBAS. Pero igual el uso/código que se ve normalmente NO explota esta característica.
Un ejemplo es cuando alguien decide (MUY inteligenteme) dejar de usar Paradox y volcarse a una base de datos como Firebird. Ahora el caudal de cambios que toca hacerle al código es impresionante….
- Toca cambiar los TDatabase de BDE a Interbase/Firebird. Este es simple… pero…
- Toca cambiar todos los TDataSet. Mucha gente mete los TDataSet en los formularios/reportes lo que es MUY mala idea. Otros son un poco mas listos y usan los TDataModules para ello, PERO, igual pueden ser muchos.
- Al pasar de un acceso basado en tablas como en paradox a uno por Sql o al cambiar DIALECTOS de Sql (como el que usa Sql Server a uno que usa Oracle) toca alterar las consultas y eso esta POR TODAS partes con codigo que encadena texto aqui y alla. Caos total.
Y la razón de todo esto, digo yo, es que nos emocionamos demasiado la primera vez que vimos lo simple que era el ENLACE de los datos y pensamos, hey! asi debo hacer toda mi aplicación!
Tecnicas de acceso a datos: La forma sencilla
Cuando uno aprende a programar conoce una de las cosas mas simples, las constantes. El ejemplo tipico es el del numero PI, el cual es algo como 3,1416. Y se nos enseña que es mas lindo hacer un
const PI = 3.1416;
Porque en fin, algun dia cambiara PI… no realmente porque asi es el código más claro. Ahora bien, la mayoría de la gente mete a lo bestia SQL asi:
lcSql := 'SELECT Id FROM Clientes WHERE Id=' + QuoteStr(Id) + ' ORDER BY '+ CampoOrden;
Y parnafernalia como esa, que esta regada aqui y alla, mezclada entro los eventos de validación de los controles, los reportes, funciones.. es como una invación marciana en una pelicula cuando el soldado a punto de morir grita !estan en todas partes! y si, este tipo de cosas tambien me asuntan.
Recuerdan las constantes? Por si acaso, el valor de PI puede cambiar pero en fin, las constantes hacen mas legible el código. Lo que propongo es muy simple: En vez de meter Sql a lo bestia, lo dejamos encerraito como buen cachorro que es en una lista de constantes, como:
unit SqlConst interface const SqlListaClientesPorId = 'SELECT Id FROM Clientes WHERE Id=%s ORDER BY %s'; implementation end.
Y ahora si, existe un UNICO lugar donde alterar las definiciones de los sql. Un nuevo campo? Se paso de una tabla a una vista? No hay problema… bueno al menos ahora es claro DONDE buscar.
Pero si toda esta carreta fuera para decir que la solución es usar constantes… no!!! porque ser programador implica más!La verdad, ese asunto de meter SQL como constantes tiene un uso limitado.
La mayoría de los sql son generados al vuelo y deben ser más flexibles… además igual no se ha solucionado el asunto de tener que cambiar de componentes de acceso a datos.
De vuelta al comienzo. Recuerdan las ventajas del modelo de acceso a datos de Delphi? Principalmente, TDataSet es una clase abstracta de la cual derivan las diversas implementaciones.
Asi que mejorando un poco, la idea es:
unit AccesoDatos interface type TGeneradorSql = class(TObject) public function GetSelect(Tablas:String;Campos:String;Filtro:String;Orden:String=''):String end; type TAccesoDatos = class(TObject) FCon:TAdoConnection; function Conectar:Boolean;public function ObtenerSql( lcSql : String ) : TDataSet; function EjecutarSql( lcSql : String ) : Integer; function ActualizarDatos ( DataSets:array of TDataSet); implementation function TAccesoDatos .Conectar:Boolean begin // Crear aqui la coneccion con la respectiva cadena de conexion... end; function TAccesoDatos .ObtenerSql( lcSql : String ) : TDataSet; begin // Llamar a Conectar. De esa manera se accese a los datos y Conectardetermina //si se soporta el modo StateFull o StateLess // Crear el respectivo TDataSet con los diferentes parametros. Ejecutar la consulta, y retornar end; function TAccesoDatos .EjecutarSql( lcSql : String ) : Integer; begin // Para comandos como INSERT, DELETE y UPDATE. Retornar el numero de registros afectados y automaticamente ejecutar en el contexto de una transaccion end; function TAccesoDatos .ActualizarDatos ( DataSets:array of TDataSet); begin // Dentro de una transaccion realizar los post a los TDataSet enviados. end; function TGeneradorSql.GetSelect(Tablas:String;Campos:String;Filtro:String;Orden:String=''):String begin // Hacer la concatenacion, como:Result := 'SELECT '+ Campos + ' FROM ' + Tablas + ' WHERE '+ Filtro + ' ORDER BY '+ Orden end; end.
Obviamente, el código que pongo es solo para exponer la idea. Entremos a detallar:
1- Existe un UNICO lugar donde se administra el acceso a datos. Lo que implica un unico lugar donde cambiar los componentes. Por ejemplo, la conexion es un TAdoConection, solo pocos metodos lo tocan asi que hacer el cambio es cuestion de minutos. 2- Metodos bien definidos para hacer selects, inserts, updates, que automatizan la logica de las transacciones, y virtualizan la creación de componentes permitiendo mayor reutilización y menor acople. Hacerle una llamado es muy simple, algo como ´DataSet := AccesoDatos.ObtenerSql(Sql_Clientes);´. Noten que nada de tocar la conexión ni de crear objetos TAdo esto TDBE aquello…. 3- Una clase que se encarga de hacer las concatenacions de las tablas, campos, filtros, orders, etc… Eso significa la posibilidad de adaptarse a los diferentes dialectos y MENOS errores por causa de concatenar mal las cosas. Entonces es mas simple: ‘lcSql := GeneradorSql.GetSelect(“Clientes”,”Id”,”Id=1”,”Id”)’ y teneros la certeza que se devuelve la cadena SQL correcta. Y podemos expandir la idea para llamar procedimientos almacenados o INSERTS/UPDATE/DELETE.
La verdad, hacer este código no demora menos de 1 semana, incluyendo un parser más sofisticado de Sql… pero es una libreria reusable y de fácil mantenimiento. Incluso haciendo esto me di el lujo de hacer una interface orientada a objetos con código asi:
oSql.Tablas.Add("Clientes")oSql.Campos.Add("Id","N")oSql.Filtro.Add("Id=1")oSql.Filtro.Add("Activo=1", AND) lcSql := oSql.Sql;
Y se puede reversar, o sea, a partir de una cadena SQL se obtiene una defincion de las tablas, campos, filtros, etc…!!!
Ahora, el asunto es que se deberia hacer subclases de acuedo a cada aplicacion. Piensen en algo como:
type TAccesoDatosFacturacion = class(TAccesoDatos) public function ObtenerClientes(Filtro:String;Orden:String) : TDataSet; function ActualizarFactura(DataSets:array of TDataSets) end;
El asunto es mantener un unico lugar que se encarge de tocar la base de datos y sus tablas. Es increiblemente compacto el código resultante y es maravilloso la facilidad de uso que se logra y las ventajas de poder alterar el acceso a datos, no solo sin afectar la interface gráfica que Delphi se encarga de ello, sino sin alterar la LOGICA de nuestras aplicaciones!
Ahora bien, si quieren un producto más sofisticado, RemObjects tiene el framework DataAbstract, lo cual es una versión mucho más sofisiticada de la idea que presento aquí y que es ideal para un desarrollo más fuerte… darle una mirada tambien les puede ayudar a entender más el concepto.
0 comments | 0 pingbacks | tags: delphi, programacion
La importancia de hacer Unit Testing
Mucho se ha dicho sobre la importancia de hacer unit testing.
Sin embargo todavia muchos programadores desconocen las ventajas que reportan tener un conjunto automatizado de pruebas…. o tal vez parece muy complicado.
Es dificil enseñarle nuevos trucos a un perro viejo, pero este es uno que vale la pena. En primer lugar, no hay que invertir dinero, se puede conseguir las herramientas de Unit Testing de forma gratuita.
Con Delphi, se usa DUnit (el cual esta integrado dentro de Delphi 2005). En la página de DUnit hay tutoriales sobre como se hace un test. ¿En esencia? Es simplemente hacer una prueba de escritorio, pero en vez de escribir sobre el papel se escribe código real, el cual queda guardado para futuras pruebas.
Tambien se puede ver como almacenar para la posteridad una sesión de depuracion…Que ventajas aporta hacer Unit Testing? Estas son algunas que personalmente he observado:
- Enfoca el esfuerzo de desarrollo en hacer código sin errores (al menos sin los obvios). El punto central de hacer Test es que el esfuerzo se pone en mantener el código funcionando correctamente y en sostenerlo de forma estable en el tiempo. Sin hacer test automaticos, el esfuerzo se diluye entre hacer nueva funcionalidad (incluso aunque sea innecesario) y en posponer la resolución de los problemas.
- Mayor confianza en el código. Es un sintoma muy común el “temor” a tocar el código fuente, porque al efectuar un cambio, este puede tener efectos colaterales y dañar funcionalidad que estaba trabajando bien antes. El tener una suite de pruebas permite detectar a tiempo cualquier efecto colaterar y permite entrar con confianza a hacer cambios internos (como por ejemplo, arreglar un código que no se entiende muy bien y es díficil de mantener) con la seguridad de que el resultado final seguira siendo correcto
- Ayuda a hacer clases correctamente. Un mal endemico en el desarrollo de software es tener código “mezclado” que hace múltiples tareas entre lógica de negocios, interface de usuarios, acceso a base de datos y código de utilerias. Este tipo de código es una fuente segura de errores, dificil de mantener y entender y muy frágil, porque el cambio en una línea de código afecta a muchas más, porque todo esta mezclado. El punto es, es horrible testear código asi. Por lo tanto, en el esfuerzo de hacer código/clases fáciles de testear como efecto secundario se fuerza a separar las tareas y en hacer código más modular, y más facil testear = más facil de entender = más facil de mantener = código más solido
- Ayuda a mantener el trabajo dentro de las fechas limites. Una recomendación es hacer el código de prueba ANTES de hacer el código como tal. Eso suena muy raro… pero es de las mejores ideas que se pueden implementar…
Al crear los esqueletos de que pruebas hay que hacer, es como tener una lista de tareas que se marcan completas cuando el código pase correctamente las pruebas.
Por ejemplo, supongamos que hay que hacer un software de facturación. En este tipo de software, hay que hacer procesos como aumentar/disminuir el inventario, devolver compras, dividir los pagos en cuotas y cosas asi. Hacer las pruebas ANTES del código es simplemente hacer esto:
::delphi procedure TestAumentarInventario begin CheckTrue(False); end;
procedure TestDisminuirInventario begin CheckTrue(False); end;
procedure TestDevolverCompra begin CheckTrue(False); end;
Se usa CheckTrue(False); para marcar que aún no se ha realizado la prueba de esa funcionalidad.
Asi, que ahora hay una lista de 3 tareas… a eso me refiero con mantener el enfoque. Ahora DUnit nos va a informar que nos faltan por completar 3 test, y nosostros entonces vamos a hacer que esos test pasen bien. Si adicionalmente llenamos en blanco el resto de la funcionalidad de nuestro software vamos a poder hacer estimativos reales sobre cuanto nos va a costar terminar el programa… y los programadores en vez de llegar al trabajo preguntandose ¿y que hago ahora? y mientras lo piensan se ponen a navegar por Internet, van a tener una lista de tareas por hacer, que les muestra su progreso y que los mantiene MOTIVADOS.
Asi que si no estan haciendo unit testing empiezen ya! Bajense DUnit y lean un poco sobre este tema y miren los tutoriales.
