Web.xml

El archivo web.xml proporciona la configuración y el despliegue de información para los componentes Web que conforman una aplicación web.
Ejemplos de componentes Web son los parámetros de servlet, Servlets y JavaServer Pages (JSP) definiciones, y Localizadores Uniformes de Recursos (URL) mapeos.

El archivo web.xml debe residir en el WEB-INF directorio en el contexto de la jerarquía de directorios que existen para una aplicación Web.
Por ejemplo, si la solicitud es client.war, entonces el archivo web.xml se coloca en el raíz_instalación / cliente guerra / WEB-INF directorio.

Faces-Config.xml

Es el archivo de configuración central de los JavaServer Faces.

Se espacifican los eventos, acciones , beans de respaldo (backend bean, bean que almacena las propiedades de los componentes UI de la página y los métodos asociados).

ui:fragment

Esta etiqueta nos sirve para introducri una nuevo UI Componente en un JSF
Básicamente sirve para los rendered.

CheckBox con JSF

If y else con Jstl

Para ello utilizamos las etiquetas c:when y c:otherwise dentro de la etiqueta c:choose

JSTL (JavaServer Pages Standar Tag Library)

No es más que un conjunto de librerías de etiquetas simples y estándares que encapsulan la funcionalidad principal que es usada comúnmente para escribir páginas JSP. Las etiquetas JSTL están organizadas en 4 librerías:

• core: Comprende las funciones script básicas como loops, condicionales, y entrada/salida.
• xml: Comprende el procesamiento de xml
• fmt: Comprende la internacionalización y formato de valores como de moneda y fechas.
• sql: Comprende el acceso a base de datos.

@SuppressWarnings("serial")

Esta anotación se utiliza para evitar un error en tiempo de compilación al implementar la interfaz java.io.Serializable y no tiene el campo llamado serialVersionUI.
Basta con añadir la línea SupressWarnings @ ( serial) antes de que su definición de clase.

¿Cómo realizar las pruebas unitarias?

Debemos probrar todos los métodos que se puedan dar errores, pero ese es a gusto del programador.
Estas pruebas hay que realizarlas al comienzo del ciclo de vida de la aplicación.
Antes y después de integrar,después de un refactor, siempre después de compilar.
Realizamoremos una serie de pruebas en busca de fallos a través de unos criterios que llamaremos pruebas de caja negra y/o de caja blanca, no son excluyentes, sino complementarias, hay que procurar usar las dos.

Esta explicado lo que es la caja negra y blanca en otro post.

Afortunadamente hay muchas herramientas para autmatizar pruebas unitarias: Maven, Ant, IDE's y CIS.

Pruebas Unitarias

Se utiliza para poder probrar que todo esta correcto en un módulo de código asi podemos saber que todo los módulos funcionan bien lo ideal es escribir todos los modulos independientes unos de otros.

Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:

• Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continua.
• Completas: deben cubrir la mayor cantidad de código.
• Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua.
• Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.
• Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.

Se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función.Pero no es obligatorio.

Los beneficios de escribir pruebas unitarias son muchos:

• El código es menos frágil.
• Hacer cambios es más seguro y fácil.
• Podemos integrar continuamente de manera rápida.
• Podemos hacer refactors agresivamente.
• Tenemos una documentación viva de nuestros APIs.
• Nos permite pensar desde el punto de vista de la interfaz y no de la implementación.
• Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.

Estandares de desarrollo

Nomenclatura:

• Nombres de clases comienzan con mayuscula y continuan con sintaxis de camello
• Nombres de propiedades/objetos comienzan con misnúscula y continuan con sintaxis de camello
• Nombres de paquetes: todas las letras en minúscula.
  

Jerarquía de paquetes:

• carpeta source foder:
• src
• test
• todos los paquetes tendrán como paquete raiz el paquete eticom
• el subpaquete será el que describa el módulo que se está desarrollando
• todas las clases deben estar en un paquete.
  

Resources de proyecto/Recursos comunes a proyectos/ Librerías>

• testNG.jar
• suite de pruebas con las clases de prueba declaradas
• commons-logging.jar
• apache-log4j.jar
• y configuración correcta de log4j.xml.
  

Responsabilidad de clases y métodos:

• una de las reglas de POO es la de unica responsabilidad de las clases más info
  

Generación de una nueva clase:

• añadir atributo Log logger
  

@SuppressWarnings("deprecation")

Esta anotación le indica al compilador para reprimir advertencias específicas que, de otro modo, genera.

Por ejemplo:
Cuando usamos java.util.Date fechaHasta = new java.util.Date("12/31/2099");
Esta clase esta obsoleta ypara evitar que salga el warning se le pone la anotación @SuppressWarnings("deprecation") y listo