| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos |
Artículo "Buenas prácticas en J2EE. Primera parte."
Este artículo contiene la primera parte de un informe que explica técnicas de gran utilidad para el desarrollo con la plataforma J2EE. Aplicando estas técnicas, podemos disminuir la dificultad y el costo de este tipo de desarrollo y mejorar el rendimiento, calidad, flexibilidad y escalabilidad de los sistemas resultantes.
Artículo "Buenas prácticas en J2EE. Primera parte." (continuación)
4. BUENAS PRÁCTICAS DE PRUEBAS La mayoría de los programadores tratan la etapa de pruebas (“testing”) como una obligación menor que deben cumplir para complacer a los superiores. Sin embargo, las pruebas de una aplicación no deberían tener lugar solamente después de su programación sino durante todo el ciclo de vida del desarrollo: Se deben definir los casos de prueba durante el análisis de requerimientos, permitiendo que los casos se apliquen a todos los requerimientos. Los programadores deberían escribir guiones de prueba antes, o como mínimo al mismo tiempo, que el código de aplicación. Este proceso asegura que cada línea de código tiene un caso de prueba y que los programadores programan la funcionalidad que se desea. Los casos de prueba deberían ejecutarse durante la integración, para verificar que no falla nada nuevo y que no han aparecido nuevos errores en el sistema. Las pruebas deberían producirse también en tiempo de despliegue, sobre el proyecto completado, para demostrar a todos los interesados que la aplicación cumple todos los fines preestablecidos de rendimiento y escalabilidad. En este apartado, se discutirán buenas prácticas que mejoran la eficiencia y calidad de las pruebas 4.1. Buena práctica número 9. Escriba primero los casos de prueba. Tradicionalmente, los casos de prueba se han ejecutado separadamente del código de aplicación. Este ineficiente proceso está cambiando rápidamente, conforme metodologías de desarrollo más ágiles requieren a los programadores escribir casos de prueba antes que el código de aplicación. Escribiendo primero los casos de prueba, se pueden obtener varios beneficios tangibles: Es más probable que los programadores comprendan la funcionalidad que se desea y que se centren más en implementar el código que satisface los requerimientos. A partir de este punto, las pruebas de integración pueden tener lugar sin impedimentos ni trabajo adicional, ya que los casos de prueba que existen aseguran el buen estado del sistema. Escribiendo primero los casos de prueba, la cultura de desarrollo da un mayor valor a las pruebas. Es menos probable que los programadores implementen código extraño que no se necesite para satisfacer requerimientos tangibles. Una de las razones más comunes por las que se dejan de ejecutar las pruebas es la falta de casos de prueba predefinidos. En las etapas tardías del proceso de desarrollo, las presiones sobre el tiempo frustran los esfuerzos de crear guiones completos de prueba. Sin embargo, aunque al principio pueda parecer un atraso, escribir primero los casos de prueba ahorra tiempo, ya que los programadores se centran en completar tareas relevantes y pasan menos tiempo en las pruebas de integración y de sistema que se producen más adelante en el ciclo de desarrollo.
Ir a la página: 1 2 3 4 5 6 7 Siguiente >>
Versión para imprimir
| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos| |