Test Driven Development presentation

En este caso comparto una presentación, que si bien tiene varios años no deja de ser interesante para introductir en este tema.

http://bloggingabout.net/blogs/dennis/archive/2005/12/14/10554.aspx

Mocking Frameworks

Le comparto una presentación muy interesante sobre el tema de Mocking, pruebas unitarias, de integración , inyección de dependencias etc.

http://altnet-hispano.pbworks.com/van-2009-11-28-mocking

Software Architecture and business objetives

El miercoles 4 de noviembre tuve la oportunidad de asistir a una conferencia del Phd Andres Diaz Pace (ADP) en donde presentó la metodologia del SEI para la documentación de arquitecturas de software. Al finalizar la presentación de Andrés varios panelistas hicieron sus comentarios y respondieron a preguntas de los asistentes.

A continuación voy a intentar resumir los aspectos relevantes del la presentación.

ADP comentó que hay muchas definiciones de Arquitectura de Software, entre ellas comentó la del SEI ("Software Architecture in Practice", Clements, 2008).
Entre los apsectos importantes que rescaté del seminario es que se tome en cuenta o no la arqteuictura de software siempre existe, en forma formal mediante procedimiento o informal o implicita. Es decir si no diseñamos arquitectura alguien en el proceso de desarrollo lo hará y de la mejor forma que pueda, con el peligro que ello acarrea.

Otro aspecto es el lugar de la arquitectura de software en el proceso de desarrollo, ADP mostró un proceso simplificado en donde se inicia por lso objetivos de negocios, luego los requerimientos funcionales, de allí la arquitectura de software y finalmente el sistema. Este es un proceso iterativo en donde del objetivo de negocio se deriva a especificaciones funcioanales de alli mediante diseño se contruye la arquitectura de software y luego el equipo de desarrollo la implementa.
Al grupo de arquitectura debe participar en todo el proceso de desarrollo de software teniendo mayor porcentaje de participación durante la etapa de elaboración del proceso, pero tambie´n requiere cierto grado de participación durante la etapa de incepción, transisión e implementación.
ADP considera incorrecto que el equipo se desvincule totalmente del proyecto luego de terminado el diseño arquitectónico, por eso es requerido un cierto grado de participación en la demás etapas.

Otro aspectos importante de mencioar es que el diseño arquitectónico permiti reducir los riesgos en el proyecto, pues se encarga de elicitar los atributos de calidad, validar la infraestructura, validar con áreas auxiliares (seguridad informatica, tecnología, stakholders etc). Cabe destacar que el disertantem comentó que involucrar a muchas áres implica un riesgo a la hora de documentar la arquitectura pues cada área tiene su propia visión del proyecto y puede querer incluir en la documentación aspectos que no son parte del diseño arquitectónico (tal vez si de documentación complementaria).

Se discutió sobre lo que NO es la arquitectura de software, y ADP dió algunos ejemplos como:
- No es la arquitectura del hardware.
- No es el modelo de datos.
- No es solo un diagrama de "cajitas" interconectadas.

De este último punto se desprende que por presiones varias los stakholders intentan reducir el tiempo de diseño para pasar rapidamente al momento de la implementación, por lo tanto la arquitectura dieñada tiene una visión muy general, no consdiera atributos de calidad, riesgos por el uso de tecnologías no estandares en la compañía etc.

Elicitación de atributos de calidad:
Estre los procesos recomendados por el SEI se comentó uno denominado QAW (Quality Atributte Workshop)http://www.sei.cmu.edu/library/abstracts/reports/03tr016.cfm
Este proceso tiene como fin comprometer a los stakholders para definir precisamente los atributos de calidad requeridos en el proyecto. Basicamente la técnica implica litar los atributos de calidad y leugo mediante votación se pondera cada atributos. Luego de eso se puede elimiar algunos meno prioritarios (o dejar su analisis para un posterior release) dejando solo los más importantes.
La técnica es simple, pero lo que no es simple conseguir que los stakholders se involucren en este aspecto, pues la visión de los atributos de calidad de cada uno puede diferir bastante.

Basicamente lso siguientes son los aspectos más importante de eta técnica:

- Centrado en el sistema.
- Focalizado en los stakeholders.
- Técnica implementada antes de definier la arquitectura.

Una sesión de QAW debería seguir los siguientes pasos, la misma está moderada por un facilitador, el manager del proyecto y el arquitecto. Es importante que tiene que tener un time frame definido y en la manera de lo poible obtener un consenco documentado.

1- Introduction to QAW (Manager)
2- Business Mision Presentation (Arquitecto).
3- Indetification of Architecture Drivers
4- Scenarios Bainstorming.
5- Scenarios priorization
6- Scenario refinemente
7- Return to 1.


Esta técnica permite concentrar el esfuerzo en el diseño de aspectos no funcionales para los atributos de calidad más relevantes para los stakholders del proyecto.
la técncia define que en la documentación de atributo de calidad se deben considerar los siguientes aspectos:

1- Estímulo: Es el evento de entrada.
2- Respuesta al estímulo.
3- Fuente del estimulo.
4- Condición del ambiente.
5- Medida de la respuesta.

Por ejemplo si el atributo de calidad es la performance una simplificación (hiper simplificada) para estos aspectos serían:

1- Estimulo: Request a una determinado servicio.
2- Respuesta al estímulo: Mesaje de respuesta en XML (especifica peso en Kb).
3- Fuente de estimulo: proceso X que corre en servidor Z.
4- Condición de ambiente: X% de CPU, Z Mb de memoria consumir por el servidor, I/O, Byterates etc.
5- Medida de la respuesta: Reqeust por segundo, %CPU y %memoria conumida por el proceso en cuestion etc.

En la documentaciónd el SEI existen tablas donde están tabulados varios atributos de calidad.

Consderaciones sobre documentación de arquitectura.

Debe tener un enfoque basado en vista. Cada vita mostrará difentes niveles de detalle de la arquitectura y representaciones para diferentes interlocutores (lógica, capas, implementación etc).
En la documentación se debe tener el trace entre una objetos de una vista y de otra.
Un mayor nivel de detalle reduce el tiempo dedicado al mentoring y el coaching a la hora de implementar la arquitectura. Esto no implica que se reduzca a cero pues el arquitecto participa en todo el proceso de desarrollo.

Por ejemplo en un vista en donde se quiera detallar aspectos de seguridad deber indicar zonas de seguridad, puntos de entrada, conexiones etc.
Si es por un tema de performance, incluiría vistas de procesos, interacción etc.

En la documentación del SEI se clasificar las diferentes vistas.

En resumen las vistas deben consdierar los siguientes aspectos:

1- Estructura del sistema en térmicos de unidades de código.
2- Interacciones en tiempo de ejecución.
3- Como se relacionan con estrucmturas no software.
4- Interfaces.
5- Comportamiento.

Tambien se puede ver desde tres perpectivas diferentes:

1- Módulos: Contrucción, analisis de impacto, pruebas etc
2- Componentes y conectores: performance , disponibilidad etc.
3- Asignación de responsabilidades: Diponiblidad , seguridad, performanceetc

Para evaluar la completitud de una vista hay que considerar la descripción de sus elementos constitutivos, mapeo entre vistas, deben existir diferentes vistas según perfil de stakholders, asegurarse que contengan información útil.

Evaluación de arquitecturas:

Luego de esta introducción el disertante comento sobre el proceso ATAM (Architecture Tradeoff Analysis Method) http://www.sei.cmu.edu/library/abstracts/reports/00tr004.cfm

ATAM provee tendencias sobre la evaluación de la arquitectura, no aspectos precisos. Esta técnica ayuda a evaluar aspectos de la arquitectura como nivel de enfioque en el producto software, detección temprana de riesgos, prácticas de ingenieria de software, aspectos de calidad etc.
Dado qeu es un proceso complejo se sugiere efectuarlo luego de tener terminada la primera iteración de la documentación de arquitectura y luego de finalizada cada etapa de elaboración de las sucesivas iteraciones.

Un aspecto que comentó como introducción el disertante fue la técnica de diseño definida por el SEI, es la ténica ADD(Atribute-Driven Desing) http://www.sei.cmu.edu/library/abstracts/reports/06tr023.cfm

De eta descripción podrai resumir que la técnia ADD permite articular lso objetivos de negocio con la arquitectura, mitigar riesgos y se considera en todo el proceso de desarrollo.

Como conslusión ADP mencionó que en el futuro próximo es importante considerar istemas que requieran gran escalabilidad (ej Facebook) o gestionados con recursos no cetralizados (ej Eclipse).

Finalmente el SEI tiene su blog en donde la comunidad puede participar

Saturn Netwotk Blog

SOA anti-patterns

Como en diseño de aplicaciones multicapas, web, cliente-servidor u otras existen patrones que describen problemas comunes y sus soluciones estandarizadas, en el caso de SOA no es la excepción. En este post no vamos a describir los patrones más comunes, pues son muchos y son de referencia para arquitectos y desarrolladores que trabajen en el diseño de servicios SOA, en el sitio de “SOA patterns”, http://www.soapatterns.org/ hay publicado muchos patrones y constantemente se agregan nuevos.
La intención es describir algunos de los anti patrones SOA más comunes con el fin de indicar como no se debe diseñar una solución SOA.


Interfaces CRUD
CRUD en la sigla en inglés que representa las operaciones de creación, lectura, actualización y borrado. Es muy común utilizar estas operaciones en relación a las bases de datos, pero en el caso de un sistema orientado a servicios especificar las operaciones de los servicios como CRUD es una mala práctica.
Por ejemplo en un servicio de manejo de ordenes diseñar en servicio en base a CRUD implica tener operaciones del este tipo

FindOrderByIDResponse FindOrderByID(FindOrderByIDRequest request);
CreateOrderResponse CreateOrder(CreateOrderRequest request);
UpdateOrderResponse UpdateOrderByID(FindOrderByIDRequest request);
DeleteOrderResponse DeleteOrder(DeleteOrderRequest request);

Si en los casos de uso se necesita crear, actualizar y borrar ordenes esta especificación de servicios es válida, pero si la creación de una orden implica varias operaciones previas (por ej verificar la disponibilidad del producto, verificar el estado de crédito del cliente y crear la orden), la operación CreateOrder debe invocar internamente todas las operaciones necesarias para crearlo pues en caso de exponer solo la creación de la orden el consumidor debe hacer las operaciones previas. Este diseño violaría el TNet 3 pues no estaríamos compartiendo solo contratos.
En resumen lo incorrecto no es el uso de CRUD para la especificación de un servicio sino un mal diseño.

Interfaces Chatty

Este anti patrón se refiere a cuando se diseña un sistema orientado a servicios con operaciones que implican un alto nivel de granularidad. En este tipo de interfaces el consumidor es el encargado de llamar a las diferentes operaciones siguientes una lógica específica para que juntos hagan una determinada acción de negocio. Lo correcto es que todas las operaciones para hacer una determina acción de negocio se ejecuten internamente en el servicio.
Por ejemplos la siguientes operaciones se basan en un diseño que aplica este anti patrón

bool ChekGoodAvailability(Ordr order);
bool CheckCreditStatus(Order order);
bool PlaceOrder(Order order);

Estos dos anti patrones están asociados pues un mal diseño de una interfaz CRUD se convierte en una interfaz chatty.

En conclusión el formato de los servicios expuestos depende fundamentalmente de la especificación de casos de uso que estos deben implementar. Por lo tanto en ciertos casos se van a requerir operaciones tipo CRUD pero en muchas otras no. Un adecuando análisis de las especificaciones funcionales seguido de un buen diseño es importante para no terminar utilizando anti patrones.

What SOA is not?

Este post tiene como fin aclarar que no es SOA, con el fin de evitar confusiones y malos entendidos a la hora de emprender un proyecto de implementación SOA.
Dino Esposito [Esposito Dino et at, 2009] indica que hay que tener claro que SOA no es una revolución, un objetivo en sí, una tecnología , ni tampoco una implementación de webservices.
No es una revolución porque hace más de 15 años que existe la infraestructura para integrar aplicaciones (EDI, CORBA, COM, DCOM etc). Lo que generó SOA fue la necesidad de integrar sistemas existente con el fin de implementar procesos de negocios usando software. Por lo tanto invocar objetos remotos, enviar mensajes ya existía antes que SOA, por lo tanto no es una revolución sino una evolución.
Tampoco es una tecnología en sí, pues SOA es totalmente independiente de proveedores y productos. Unos de los mayores beneficios de SOA es que se aplican sus principios a una organización en particular. No se debe pensar una implementación SOA en base a productos del mercado, se debe pensar en SOA tomándose en tiempo necesario para entender sus principios y aprender cómo aplicarlos en toda su infraestructura.
Decir que SOA son webservices es un error común pues a la hora de implementar los webservices son los más utilizados como mecanismo de comunicación entre los sistemas que forman la infraestructura SOA. Por lo tanto no todas las soluciones SOA utilizando webservices y no todos sistema basado en webservices es una implementación de SOA.
Como venimos diciendo ante de pensar como implementar SOA se debe tener bien definidos los procesos de negocio que suponemos que se van a mejorar mediante la implementación de SOA. Por lo tanto el objetivo no es implementar SOA sino mejorar uno o varios procesos de negocio determinados. Luego de analizar los procesos involucrados, la infraestructura, aplicaciones, tiempo y presupuesto disponible recién en ese momento estaremos en condiciones de decir si SOA es aplicable o no.

Referencias
[Esposito Dino et at, 2009], “Architecting Microsoft .Net Solution for the Enterprise”, Microsoft Press, pag 229 a 236.

Reflections about SOA implementation in the enterprise.

El tema de SOA no es nada nuevo, pero a la hora de querer conocer sobre este interesante tema el problema no fue encontrar información, sino todo lo contrario, clasificar y sacar conceptos útiles de las gran cantidad de información al respecto.
A mi criterio el tema de SOA fue un gran boom hace 6 o 7 años y luego fue madurando para ser un paradigma aplicable con exito en empresas donde la madures de sus procesos justifique la gran inversión que requiere implementar SOA. No solo es cuestión de soft y hard, sino también de un cambio cultural muy importante en la compañía. Es común que cada área de negocio tenga su propia genencia que sub procesos independientes y prioridades diferentes. por los general es obvio que todas está alineadas a un objetivo de negocio común, pues sino estraríamos en otros problema que es más un análisis de administradores de empresas y consultores asociados.
Pero de todas formas esta diferentes prioridades hace que a larga cada área sea como silos aislados en donde emprenden la contrucción de aplicaciones para resolver determinadas área de negocio, sin pensar (o poco) en lo que implementa las otas áreas.
Como consecuencia tenemos casos de duplicación de funcionalidad, repostorios con datos con entidades redundantes (por ej varias tablas de clientes o de proveedores).
La estandarización de esto requiere de un área que tenga una visión transversal a todas las áreas para poder alinearlos, definir estándares de integración, desarrollo , deployment etc con el fin de integrar las diferentes áreas de negocio. Esta área deberia estar formado por especialistas en las diferenes ramas del desarrollo y arquitectos empresariales.
Volviendo al tema de SOA, una vez que tenemos los procesos, podemos pensar en la implementación en sistemas software (primero los procesos , despues el software).
Ahora, para los más ansiosos paso a describir un resumen (o recordatorio según en caso) de los que es SOA desde el punto de vista ténico.


Arquitectura orientada a servicios

Servicios

Los servicios son sistemas autónomos, que poseen una especificación definida que pueden ser accedidos en forma remota desde otras aplicaciones de la compañía.
Desde el punto de punto de vista del consumidor del servicio no interesa como está implementado sino cual es el mensaje de entrada a recibir y cuál es el formato de la salida, de esta forma se pueden crear sistemas altamente escalables, distribuidos y reutilizables.

Para que los servicios puedan forma parte de una arquitectura orientada a servicios deben tener al menos las siguientes características

• Reusables: Proveen servicios de negocio que pueden ser utilizados por varias aplicaciones.
• Proporcionar un contrato formal: Indica que establece una interface formal para los mensajes de entrada y de salida. En la práctica se debe los mensajes tienen formato XML, por lo tanto se deben exponer esquemas XML (XSD) y no clases.
• Deben tener bajo acoplamiento
Significa que un cambio en la implementación de alguno de ellos debe afectar lo mínimo posible a los demás.
• Deben permitir la composición entre ellos.
Esta funcionalidad permite componer el resultado de la ejecución de varios servicios para ofrecer un solo resultado. En la práctica esto se podría implementar con un Enterprise Service Bus.
• Deben ser autónomos.
Indica que su implementación y administración se debe poder hacer independientemente de los demás, eta característica está muy asociada con la de bajo acomplamiento.
• No deben tener estado.
Indica que el servicio recibe el mensaje de entrada, lo procesa y luego responde el resultado sin mantener estado alguna entre ejecuciones.
• Deben poder ser descubiertos.
El descubrimiento de lo servicio es un factor muy importante para poder administrarlos, de esta forma el sistema consumidor puede conocer su especificación en un forma simple. Este proceso se implementa con un registro de servicios y una herramienta de UDDI.

TNets de SOA

En la práctica se definen 4 reglas que debe cumplir un sistema basado en SOA , estas reglas se las denomina TNets de SOA [Esposito Dino et at, 2009]

TNet N° 1; Las fronteras deben ser explícitas

La interacción con los servicios se debe hacer mediante interfaces públicas. Los métodos en la interface representan los puntos de entrada en el servicio y los datos en la firma de los métodos representan los mensajes de entrada y salida del servicio.
Las interfaces deben ser lo más simples posibles y no deben exponer datos internos a los servicios, la implementación interna de los mismos debe ser transparente para el consumidor.

TNet N° 2 ; Los servicios deben ser autónomos

Para el caso de los servicio esta regla indica que cada servicio debe poder ser implementado, administrado y versionado en forma independiente del sistema en el cual es implementado y consumido. Esto no indica que los servicio deben estar totalmente aislados del resto del sistema, lo que indica que debe tener el menor acoplamiento posible. Por lo tanto si necesita comunicarse con otros servicios lo debe hacer mediante contratos y políticas.

TNet N° 3: Usar contratos , no clases

Unos de los objetivos de SOA es la interoperabilidad, o sea todo servicio debe tener una inteface pública basadas en estándares de la industria e independiente de la plataforma. En el caso de un sistema basado en componentes las interfaces entre ellos comparten clases, para el caso de SOA esto no es válido porque el sistema sería dependiente de la plataforma.
Estas interfaces públicas se basan en contratos de servicios basado en mensajes.
Los mensajes compartidos son documentos XML y su contrato está especificado mediante esquemas xml (XSD).
Las diferentes implementaciones de SOA convierten esos mensajes XML en clases específica de una determinada plataforma y convierten las clases de respuesta en sus correspondientes mensajes XML como respuesta al consumidor del servicio.


TNet N° 4: La compatibilidad es basada en políticas

Que un servicio sea accesible y que lo pueda llamar no es una buena razón para el consumidor lo invoque. Los servicios y contratos son necesarios pero no suficientes, estos indican que es lo que se envía al servicio y que se espera de él.
Este TNet se refiere a la semántica de compatibilidad entre servicios, que un servicios haga exactamente lo que el consumidor espera. Esta semática se expone vía un acceso público y una política estándar. El estándar WS-Policy [W3C WS-Policy, 2007] específica como se debe implementar este TNet

Gobierno SOA

De la definición de SOA se desprende que para poder hacer una correcta implementación y mejorar el ROI es necesario un gobierno SOA, esto implica el proceso para poder administrar los servicios, publicarlos, controlar las versiones etc. Este factor es imprescindible porque en caso contrario no se puede aprovechar las ventajas que provee este estilo de arquitectura.

Según Bobby Wolf , Consultor WebSphere J2EE de IBM [Woolf Bobby, 2007], un proceso de gobierno SOA debe manejar al menos los siguientes aspectos.

• Definición del servicio
Involucra la técncias y herramientas que permiten identificar, describir la funcionalidad y comportamiento de un determinado servicio

• Ciclo de vida del servicio
Como todo desarrollo software los servicios deben respetar un ciclo de vida de desarrollo, para el caso particular de los servicios estos pueden tener los siguiente estados.
1. Planeado.
Cuando un nuevo servicio está siendo diseñado, pero aún no implementado
2. En prueba.
El servicio está implementado en un ambiente de prueba para que pueda ser probado por el grupo correspondiente.
3. Activo
En este estado el servicio está disponible para ser consumido y por lo tanto se considera un servicio productivo. Esto implica que debe tener alta disponibilidad no se puede dar de baja o modificar sin un adecuado proceso que mitigue el impacto en los consumidores.
4.Obsoleto:
En este estado el servicio aún está activo, pero su funcionalidad es obsoleta y por lo tanto a partir de pasar a este estado no se deben aceptar nuevos consumidores y se debe comunicar que el servicio será reemplazado.
5.Eliminado:
En este estado el servicio ya no está más disponible, muchas veces es inevitable y no siempre se pasa a este estado en forma planificada. Cosa que se debe evitar para evitar el impacto en los consumidores.

• Versionado
Los servicios tienen cierta funcionalidad que satisfacen una especificación funcional específica, por lo tanto el servicio puede cambiar por cambios funcionales, por errores detectados u otro motivo. Esta situación inevitable en todo software requrie ser adminstrado en forma correcta para evitar perjudicar a los consumidores. Lo que se debe hacer es versionar los servicios manteniendo las versiones antiguas disponibles hasta que por algún motivo se se consideren obsoletas.
Para versionar existen varias técnias y cada una tiene sus pro y contras y algunas de ellas son mandatorias cuando se implementan los servicios en determinada tecnología que solo utiliza determianda técnica. Como técnicas podemos mencionar:
- Cambio de nombre del servicio con un sufijo que indique la versión.
- Agregado de parámetros opcionales en la espcificación de la interface.
- Agregado de información de la versión en la cabecera de los mensajes.
- Enrutamiento dinámico por contenido, en donde el sistema envía el mensaje a la versión correspondientes.

• Migración
En muchas situaciones en que el servicio evoluciona de versión el consumir puede seguir usando alguna versión antigua, pero esto no siempre es así y necesariamente el cosumidor debe migrar de versión porque la nueva provee funcionalidad que justifican el esfuerzo , porque la versión actual se queda obsoleta etc. El proveedor del servicio no puede depender de la migración de los consumidores, a los sumo proporciona la mayor información para que estos migren en sus propios tiempos.

• Registros de servicios
Para que los consumidores puedan acceder a los servicios primero debe saber donde están ubicados y como acceder a ellos. Además permite administrar las versiones de los servicios.
Una vez que el consumidor comienza a invocar el servicios depende de él, por lo tanto no alcanza con publicar el servicios sino que debe existir un mecanismo para regitrar las dependencias entre lo servicios y los consumidores incluyendo notificaciones a los consumidores cuando hay cambios en el servicios publicado o cuando va a ser pasado al estado obsoleto.

• Modelos de mensajes de los servicios.
En una invocación de servicios el consumidor y el proveedore debene estar de acuerdo con el formato de los mensajes a intercambiar. Para evitar el caos que searía ponerse de acuerdo entre grupos de trabajo que separados, decenas de servicios y de consumidores se adopta utilizar un modelo de datos canónico.Un modelo de datos canónico es un grupo de formatos de datos que es independientes de cualquier aplicación y compartida por todas ellas. Dentro de los procesos de gobierno SOA debe haber uno que en forma neutral encargado de definir estos formatos de datos comunes.

• Monitoreo
Es un sistema SOA se debe garantizar un determina Nivel de Servicio Acordado (SLA), pues la caída de cualquier de ellos puede afectar el funcionamiento de los consumidores y de servicios asociados si el que falló por parte de una composición de servicios.
El sistema de monitoreo es el encargado de detectar y prevenir problemas antes que ocurran midiendo los recuros de lso servidores donde están implementados los servicios, si los tiempos de respuesta están dentro de los valores predeterminados etc.

• Propiedad del servicios
Cuando una aplicación usa un servicios, ¿quién es el responsable por el servicios?. La definición es ambigüa y se debe determinar en forma clara para evitar malos entendidos. En grandes empresas puede ser un área provea servicios para acceder a información referente a ella,pro lo tanto en ese caso el área de IT de esa área de negocio es la responsable por la diponibilidad y mantenimiento del servicio. En el caso de sistemas empresariales formado por composición de servicios esta responsabilidad se solapa, por lo tanto debe haber una cooperación entre analisistas de negocios, arquitectos empresariales, arquitectos de software, reponsables de tecnología y de áreas de desarrollo para alinear todo lo referente a los servicios al negocio de la empresa.

• Pruebas de los servicios
Como todo sistema software los servicios pasan por un estado de pruebas antes de implementar en un sistema productivo. Estas pruebas deben ser tanto funcionales como técnicas y las debe hacer el área proveedora de los servicios. Los consumidores lo único que debe probar es su propia funcionalidad y la conexión con los servicios consumidos, pues pueden asumir que los servicios publicados funcionan correctamente.

• Seguridad en los servicios
¿Cualquier usuarios puede acceder al servicios? ¿Todos los datos expuestos son públicos?, ¿La información compartida debe transmitirse por canales seguros? ¿Cómo se maneja el sistema de auditaría para evitar invocaciones no autorizadas?. Estas y muchas preguntas relacionadas con la intergradidad de los datos manejados y la disponibilidad de los servicios la maneja el área de seguridad y por lo tanto estos aspectos se deben considerar en la etapa de diseño de los servicios.


Conclusión:
SOA es un importante paradigma que si es bien aplicado puede ayudar en mucho a la integración de las áreas de negocio de la empresa, mejorar la reusabilidad de los desarrollos, tener un leguaje común de modelado etc. Los proveedores suelen poner como latigijo el tema de la mejora del ROI, este es un tema en donde no pude profundizar y no se que tan fácil es calcularlo.
Lo más importante para implementar SOA no es la técnología aplicada, productos y habilidades ténicas, sino procesos bien conformados, integración de las áreas y lo más importantes cambios cultural para pensar en "SOA" de los gerentes de negocios, de IT, analisistas y lideres de proyecto.
Luego de salvado este paso (nada fácil por cierto) pasamos las habilidades de la gente ténica de IT, deben pensar en el árbol pero tambien en el bosque para no plantar un eucalipto en un bosque de pinos, usar patrones de la industria para independizar los servicios de la plataformas del consumidor , diseñar pensando en la reutilización (en la medida de los posible) entre otroas cosas.
Por último, como los procesos de negocio cambian constantemente (como dice el famoso refrán "lo único constante es el cambio"), los sistemas que forman la solución SOA deben ser lo más flexibles posible para poder seguir ese cambio, ese también es una gran desafío.

Referencias


[Esposito Dino et at, 2009], “Architecting Microsoft .Net Solution for the Enterprise”, Microsoft Press, pag 229 a 236.

[W3C WS-Policy, 2007], Web Services Policy 1.5 – Framework,
http://www.w3.org/TR/ws-policy .

[Woolf Bobby, 2007], “Introduction to SOA governance, Governance: The official IBM definition, and why you need it”,
IBM SOA Governance

Cloud Computing I

“The cloud is a virtualization of resources that maintains and
manages itself” Kevin Harting

Entre las nuevas tendencias en IT surge un nuevo paradigma para implementar aplicaciones
empresariales y servicios que difiere del conocido datacenter centralizado donde tenemos todas nuestras aplicaciones, bases de datos, servidores de email, de archivos etc.
Aprovechando las ventajas provistas por las mejoras en las redes de datos, virtualización, sistemas de almacenamiento entre otros este nuevo paradigma nos permite implementar aplicaciones dentro de una infraestructura no centralizada y compartida, básicamente está es la filosofía de cloud computing.
En este artículo veremos los conceptos básicos de este paradigma, describiremos aplicaciones y servicios provistos por los mayores proveedores de software y aspectos relacionados con los pros y contras de implementar en la nube aplicaciones empresariales.

¿Que es cloud computing?

“..moving computing and data away from the desktop and the portable PC and simple displaying the results of computing that take place in a centralized location and is then transmitted via the Internet on the user’s screen” John Markoff

Probablemente el término “cloud” surge de la representación que se hace a Internet en los diagramas de redes.
Conceptualmente cloud computing proporciona un nivel alto de abstracción de la nube en donde los desarrolladores y administrador implementan aplicaciones utilizando frameworks y herramientas que los abstrae de la implementación física como puede ser detalles de routers, servidores, unidades de almacenamiento etc.
Por lo tanto el usuario del servicio no necesita preocuparse de cómo se implementa esas tecnologías y como se mantienen. Solo se preocupa de como acceder a sus aplicaciones desde cualquier lado y su nivel de disponibilidad para satisfacer los requisitos de las aplicaciones.
En realidad con cloud computing se puede acceder a funciones y servicios con necesidades de cambios dinámicos.
Los frameworks que se utilizan en la nube deben proveer los siguientes mecanismos:

- Automonitoreo
- Registración y descubrimiento de recursos.
- Definición de acuerdos de nivel de servicio SLA.
- Reconfiguración automática.

Desde el punto de vista del usuario en la nube los recursos están virtualizados y se mantienen y administran por si mismos.

Mitos sobre la nube

Cloud computing no es grid computing, unit computing ni software-as-services SaaS,
pero estos paradigmas pueden utiliza una red en la nube como forma de implementarlos
El cloud no solamente es un cambio tecnológico sino también de negocio tanto para
los clientes que la utilicen como los proveedores de software e infraestructura tecnológica.
Gartner publicó los 8 mitos más comunes con respecto a cloud computing

Mito 1: Cloud computing es un infraestructura o una arquitectura.
Mito 2: Cada suministrador tendrá una nube diferente.
Mito 3: SaaS es la nube.
Mito 4: Cloud computing es una nueva revolución.
Mito 5: Toda los sistemas remotos son Cloud computing.
Mito 6: Internet y la Web con la nube.
Mito 7: Todo estará en la nube.
Mito 8: Cloud computing elimina las redes privadas.

Soluciones implementadas

Existen varios proveedores que ya poseen sistemas implementados en la nube y que están disponibles para ser utilizados en forma gratuita o mediante el pago de un costo según las caracteristicas suministradas.
Ejemplo de ellos son los servicios de Amazon mediante salesforce.com, LiveMesh de Microsoft o Moozy de EMC para compartir recursos, App Engine de Google o Blue Cloud de IBM son algunas de las aternativas disponibles. Para mayor detalle ver referencias.
La NASA tiene disponible "NEBULA Cloud computing platform", que son servicios basados en Cloud Computing que provee componenetes open sources y sistemas self-services.

Conclusiones

Cloud computing es el resultado de la evolución de la tecnología aplicada a la implementación de infraestructura hardware y estándares abiertos para interoperar sistemas.
Sobre la nube se pueden implementar servicios como software-as-service que son productos software expuestos en la nube como servicios como por ejemplo Google Docs o Microsoft Office Online, platform-as-service como por ejemplo los sistemas multi-petabyte de EMC Atmos o SimpleDB de Amazon.
Otro aspecto importante es el cambio en el modelo licenciamiento pasando de un sistema de compra o alquiler de la infraestructura a pago por uso.
Grandes proveedores como Micrososft, Google, Amazon, IBM, HP, Citrix o EMC entre otros ofrecen servicios en la nube, con carácteristicas muy variadas.
Por lo tanto es importante considerar a la hora de utilizar servicios en la nube los aspectos de seguridad, privacidad, disponibilidad, fiabilidad y cumplimiento de estádares aplicables a sistemas implementados en la infraestructura dentro de la compañía.

Con appistry http://www.appistry.com/ se pueden generar redes Cloud Computing locales.

Referencias

IBM Blue Cloud
http://www.deitel.com/ResourceCenters/Programming/CloudComputing/CloudComputingIBMsBlueCloud/tabid/3063/Default.aspx

Microsoft Cloud Computing Tools
http://msdn.microsoft.com/en-us/vstudio/cc972640.aspx

Amazon Cloud Services
http://aws.amazon.com/products/

EMC Cloud Optimized Storage
http://www.emc.com/products/category/subcategory/cloud-optimized-storage.htm

Google Cloud App Engine
http://code.google.com/intl/en/appengine/

NEBULA Cloud computing platform
http://nebula.nasa.gov/

¿Es socio del MUG?, www.mug.org.ar

Interoperability I

Es cada vez más común que los sistemas empresariales actuales tengan que
interactuar entre ellos, con productos implementados dentro de la compañía o con
sistemas implementado en Internet o dentro de otra compañía u organismos
gubernamentales.

En ese contexto existieron muchos protocolos de comunicaciones, desde el manejo
de la comunicación directamente utilizando el protocolo TCP/IP hasta modernos
sistemas de integración modernos donde se maneja seguridad, estabilidad,
fiabilidad, direccionamiento, enrutamiento etc.

Los primero protocolos de comunicaciones estaban diseñados para interconectar
sistemas que corrieran bajo la misma plataforma o lenguaje, de ellos surgió el DCOM
para plataforma Microsoft, CORBA para Java etc. Para el caso de necesitar
interconectar sistemas heterogéneos se debía recurrir e protocolo de bajo nivel como
TCP/IP o RPC, hoy en día se siguen utilizando para comunicarse con versiones
antiguas de algunas plataformas como SAP o Host.

Debido a esta gran torre de Babel de protocolos varios importantes proveedores de
software y hardware como Microsoft, Sun, IBM, Intel, CA, Entrust, BEA, TIBCO entre
otros coordinaron la creación de un estándar de comunicación para interconectar sus
plataformas.

Con el advenimiento del XML como lenguajes para especificar datos y metadatos se
dio un gran avance en el tema, luego se crearon las especificaciones de los XML
WebServices, en sus versiones más básicas se pudo efectuar interconexiones básicas
entre varias plataformas, como por ej .Net de Microsoft con Java de Sun.

Para poder satisfacer requerimientos de interoperabilidad más exigentes se creó el
Organization for the Advancement of Structured Information Standards OASIS.
OASIS es un consorcio de organismos con el fin de crear estándares abiertos para la
intercomunicación de sistema de información globales.

Con respecto a los webservices se generaron la familia de estándares WS*, que
extienden la especificación original para los webservices otorgando especificaciones
para agregar seguridad, manejo de transacciones, de enrutamiento etc.

En lo que respecta a seguridad se crearon la familia de estándares WS-Security ,
que tiene como objetivos establecer mecanismos de intercambio de mensajes SOAP
en forma segura.

Utilizando protocolo independientes de la plataforma

Una forma de evitar todos los problemas asociados con el marshaling entre
plataformas es utilizar protocolos que sean independientes de ellas.
Luego de un gran esfuerzo de los mayores vendors de software y hardware (Intel,
HP, Sun, IBM, Microsoft, CA etc) se formalizaron una serie de estándares para
manejar un lenguaje común a la hora de interconectar sistemas heterogéneos.

De todos estos estándares lo que nos interesan son los referidos al uso de servicios
web como mecanismo de comunicación.
De este trabajo surgió el WS-Basic Profile 1.1 que consta de un conjunto de
especificaciones para servicios web no propietarias que agrega clarificaciones,
refinamientos, interpretaciones y ampliaciones de especificaciones que promueven la
interoperabilidad.
Este conjunto está formado por las especificaciones de WSDL v1.1, UDDI v2 y SOAP
v1.1 .

Conclusión
La correcta integración de plataformas heterogéneas necesita , valga la redundancia
, la correcta integración de los proveedores que las crean, pues son lo que deben
generar herramientas para poder interconectarse con otros sistemas utilizando un
lenguaje común.
Los estándares de OASIS, en especial los WS* son un importante paso en este
sentido

Referencias

Especificación WS-Securiy, http://docs.oasis-open.org/wss/2004/01/oasis--
200401-wss-soap-message-security-1.0.pdf

World Wide Web Consortium http://www.w3.org/

Introducción TDD III

Continuando con esta serie de posts, voy a describir el uso de una herramienta que me pareció muy útil para probar servicio Web y Rest, me refiero al SoapUI.
En este caso voy a describir la funcionalidad que tiene la herramienta para crear objetos mocks que simulen un servicio Web, en la documentación del SoapUI los denominan MockService.

Los objetos Mock son objetos que permite simular los servicios externos al código que queremos probar.
Por ejemplos si estamos probando una componente de acceso a datos necesitaríamos tener acceso a la base de datos, que esta contenga datos de prueba válidos etc, por lo tanto dependeríamos del estado de la base de datos, la conectividad a ella y tener los permisos necesarios. Una alternativa sería simular el comportamiento de la base de datos utilizando objetos simulados que tenga el comportamiento esperado para el sistema real antes determinado conjunto de datos de entrada.

Luego de esta breve introducción vamos a ver como implementar MockServices usando el SoapUI

Lo primero que debemos hacer es generar un proyecto SoapUI en base al WSDL del servicio que queremos simular. Le asignamos el nombre TestCreditRiskService y habilitamos las opciones “Create Test Suite” y “Create Mock Service” dejando los otros valores por defecto sin alterar.

En la ventana “Generate Test Suite” dejar las opciones por defecto.

Para hacer una prueba manual del servicio se utilizan los mensaje xml de entrada creado por la herramienta, por defecto se crea uno, pero se pueden crear todos los necesarios con le menú contextual sobre el nombre del servicio.

En este ejemplo el servicio original está corriendo en la máquina local y los datos válidos de prueba son dni=12345678 y dni=23456789, de lo cuales obtenemos reportes de riesgo crediticio diferentes.

Para agregar un objeto Mock para un servicio Web (MockServices) se puede utilizar el creado cuando

se generó el proyecto o bien con el menú contextual sobre la interfase.

Este MockServices implementa el patrón de Service Stub para acceder a la simulación el servicio web original o bien al servicio original, esto se camb

ia seleccionando el endpoint correspondiente.

Para el MockServices creado asignamos un Response simulado en base al Request2

Los endpoint asignados a los mockservices se puede ver directamente invocando en el navegador la url asignada al MockService.

Por lo tanto si vamos a nuestro request original podríamos ejecutar el mismo pero invocando al MockService creado.

Agregamos el endpoint de la interfase RiskClientServiceSoap para que use como interfase de entrada.

Una vez configurado podemos iniciar el servicio simulado con las opción Start.

El MockService ya está corriendo, el último paso de configuración es redireccionar nuestra interfase del servicio original al servicio simulado.

Conclusión:

Utilizando el SoapUI se pueden hacer pruebas unitarias de servicios web en un forma muy simple, además permite hacer pruebas de carga.
Con los MockService podemos además empezar a dsarrollar el código que lo invoca antes de que la implementación real del servicio esté disponible.
Obviamente que está situación es útil cuando el contrado ya está bien definido y la implementación real tenga los menores cambios para que no impacte lo que ya se hizo.

Introducción TDD II

Pruebas unitarias con NUnit
A la hora de confeccionar el test unitario de una aplicación bajo NUnit, lo primero con lo que de debe contar como se mencionara anteriormente, es con los casos de test, luego se debe escribir el código de testeo, este código tiene una estructura especial y cuenta con una serie de atributos que serán interpretados mas adelante por el motor de NUnit. El código especialmente creado para este fin, contará con Assertions, que van a probar el correcto funcionamiento de la aplicación, en el caso de no tenerlos, el test fallara si el método testeado devuelve una excepción.

Asserts

Una aserción, o instrucción Assert, prueba una condición especificada
como argumento para el método Assert. Si la condición se evalúa como
true, no se produce ninguna acción. Si la condición se evalúa como
false, se produce un error en la aserción. Si la ejecución se realiza
bajo el depurador, el programa entra en el modo de interrupción.
Más información sobre Aserciones en el código administrado
Las aserciones son una base importante en los tests unitarios, si la aserción falla, se reporta el error. Si un test contiene mas de una aserción, las subsiguientes a aquella en donde se produce la falla no serán ejecutadas, ya que el test en ese caso ha fallado, es por esto que es más que recomendable, probar una sola aserción por test.

Las Aserciones deben ser utilizadas en aquellos casos en donde se requiera algún tipo de evaluación sobre un valor devuelto por un método, o por ejemplo en casos donde se evalúan condiciones en función del resultado de la ejecución de un método.

A modo de ejemplo, si se tiene un método que suma dos números, el test a realizar, será, la comprobación, del valor resultante de la ejecución del método, contra un valor esperado determinado. Existen diferentes tipos de Aserciones, que van a proveer al programador de la aplicación de test unitario, de la facilidad, para crear a partir la combinación de los mismos, test unitarios sólidos.

A continuación se enumeran los distintos tipos de aserciones provistas por Nunit. Y se recomienda visitar en link que se encuentra mas adelante, para obtener un detalle completo de los distintos métodos y sobrecargas que de la clase NUnit.Framework.Assert ofrece, agrupados por tipo.
Tipos de Aserciones:
• Equality Asserts
• Identity Asserts
• Compararion Asserts
• Type Asserts
• Condition Asserts
• Utility Methdo s
• String Assert
Para mas detalles
Atributos
Son utilizados por NUnit para la identificación de los tests, en versiones anteriores, la identificación se hacia en base a herencia y a partir de naming conventions, es a partir de la versión 2 de NUnit que la identificación de los test unitarios se da, a partir de ciertos atributos.

Estos atributos, están incluidos en el Namespace NUnit.Framework, cada clase que los use debe incluir el using correspondiente, y el proyecto debe referenciar a el assembly, nunit.framework.dll.
Para mas detalles
La Interface
El UNit se puede ejecutar de dos formas, utilizando los comandos de consola o utilizando la interfase gráfica, la primera opción es ideal para automatizar el proceso, por ejemplo desde un PostBuild en el Visual Studio .Net o desde una tarea de Nant.
Como se puede apreciar el resultado de la ejecución presenta los distintos tests unitarios dispuestos en forma de árbol.
Luego de la ejecución se puede apreciar por medio de un color el resultado del mismo.

Verde = OK

Amarillo = No se ejecutó.

Rojo = Falla

Hacia la derecha se puede apreciar por medio de una interface de solapas los logs de los tests, que proveen amplia información sobre los test unitarios ejecutados, y errores que se van produciendo.
Esta interface también brinda la opción de seleccionar los tests unitarios a ejecutar, y se recarga automáticamente cuando se recompila el código.

Creando el proyecto de pruebas unitarias en MS Visual Studio .Net

Una vez creado el proyecto de Test en MS VS .Net, que contendrá la o las clases con los métodos que ejecutará el NUnit, lo que sigue es:

En cada clase importamos el espacio de nombres agregando:

 using NUnit.Framework;

Establecemos el atributo que índica la clase que contiene las pruebas, con lo cual, previo al nombre de la clase agregamos "[TestFixture]", por ejemplo:

                                                   Contraer

namespace MyCompany.Application.Project.TestCases

{    

    [TestFixture]

    public class TestCase

    {

                      ...

    }

    ...

}

Podemos además incorporar un metodo que inicialice variables a utilizar indicándolo previamente con [SetUp]:

 Contraer

[SetUp] 

public void Init() 

{ 

      ... 

} 

Especificamos cuales son los métodos sin retorno

de resultados (void) de prueba que el NUnit deberá ejecutar con la cláusla [Test], ejemplo:

  Contraer

#region Test Method1

[Test]

public void TestMethod1()

{

      ...;

}

#endregion

El siguiente es un ejemplo simple:

  Contraer

using System;

Para ampliar el concepto de los Asserts se va dar un ejem

plo sobre su utilización.

Como se puede apreciar en el siguiente ejemplo, el método SetUp, quien cuenta con el atributo [SetUp], posee la lógica necesaria para crear los objetos que serán utilizados durante los tests unitarios.

Mas adelante, es posible distinguir el método BagMultiply, este es un test que cuenta con varios Asserts, como se puede apreciar en el código, por medio de estos 3 Asserts, se testea el buen funcionamiento del mismo.

En los dos primeros casos, los asserts son de comparación, como parámetros se pasan, en primer lugar el valor esperado y luego el valor resultante del método que se prueba.

Por último tenemos un assert que va a evaluar la condición que se pasa por parámetro.

Para este test, con cualquiera de los asserts que falle, el resultado del test será negativo.

Luego se compila el proyecto quedando preparado para ejecutarlo desde NUnit.

Conclusión:

Con esta herramienta se pueda ejecutar pruebas unitarias en forma automática.
Junto con herramientas de integración continua como el Hudson con un control de fuentes como SVN, de scripting de tareas con el Nant, de generación de mock objets como NMock se puede generar un entorno basico para automatizar las pruebas unitarias.

Comercialmente está el Team Fundation Server que permite generar los casos de test, hacer el deploy y automatizar las pruebas, el analisis de estas herramientas de este tipo queda para otro artículo.

Referencias:

1. NUnit Framework, http://www.nunit.org

Introducción al TDD I

Pruebas unitarias

Introducción:

El diseño de un software es un factor muy importante pues afecta a todo el ciclo de vida del desarrollo y la calidad del software creado. Un buen diseño permite al sistema satisfacer principalmente los requisitos funcionales pero también los no funcionales como mantenibilidad, seguridad, performance, usabilidad etc. Existen varias técnicas de diseño cada una con sus características particulares. En este artículo vamos a describir los aspectos fundamentales del desarrollo de software basado en pruebas (TDD; por sus siglas en inglés).
Por lo tanto TDD no es una metodología de pruebas sino de diseño donde se comienza con el diseño y desarrollo de los casos de pruebas y luego con la implementación del código funcional hasta que las pruebas se puedan ejecutar sin errores.
Los casos de prueba además sirven para especificar los casos de uso en formato ejecutable y esta técnica permite diseñar el software en niveles de abstracción desde una granularidad chica hasta la más grande.

Beneficios de realizar las pruebas unitarias:

En cuanto al código

• Es fácil de mantener.
• Se torna más comprensible.
• Tiende a estar mejor diseñado.
• Antes de escribir código, fuerzan a detallar los requisitos de una manera útil.
• Mientras escribe el código, evitan un exceso de funcionalidad. Cuando se pasan todos los casos de prueba, la función está completa.
• Cuando se hace refactorización de código, aseguran que la nueva versión se comporta de la misma manera que la antigua.
• Cuando se mantiene código, ayudan a asegurar que los cambios no alterarán código ajeno.
• Cuando se escribe código en equipo, aumenta la confianza en que el código que se está a punto de enviar no va a romper el de otras personas, porque se pueden ejecutar las pruebas unitarias de ellos antes.
• Los test unitarios actúan como documentación.
• El conjunto de test unitarios proporciona constante retroalimentación de cada uno de los componentes.
• La detección de errores se ve facilitada.
• El tiempo de depuración se reduce.
• El conjunto de tests actúa como una red de seguridad contra regresiones en los bugs.
  
  

Características de un buen Test:

• Un test debe probar el qué y no el cómo, debe asegurarse que la funcionalidad del código a probar se cumpla en forma correcta y no prestar atención a como lo logra.
• Es muy limitado en su alcance.
• Se ejecuta y sucede de manera independiente.
• Revela claramente su intención.
• Debe poder ser ejecutado en forma automática cada vez que se modifique el código probado.
  
• Usa ha menudo stubs y mock objects.

Desventajas de las pruebas unitarias manuales.

• Se puede escribir una aplicación de prueba para hacer el testing. Si luego de varias semanas se quiere volver a hacer el testing el código ha sufrido tantas modificaciones que seguramente la aplicaciónd e prueba inicial ya no sirva y tenga que volver a construirse.

• En proyectos grandes podrá haber decenas de clases y muchas librerias.Es muy dificil escribir pruebas separadas por cada una de las clases en el proyecto y mantener todas ellas para futuros pruebas.

• Probar apliaciones requiere un tester humano.Se puede probar varias posibilidades al principio, pero es dificil recordar todos los casos para repetir en el futuro, se deberían documentar aparte teniendo que mantener los casos de pruebas y la documentación.
  

• Cuando la prueba es manual, el tester debe verificar el resultado de la misma y por lo tanto deber tener todo el conjunto de resultados posibles para cada prueba

• Es muy poco practico repetir todo el tiempo todos los casos manualmente antes de que salga un release. Esto llevaria muchas horas o días para completar las pruebas unitarias de todas las piezas de código.

• La ejecución de pruebas unitaria en forma manual es muy tedioso y tendiente a errores.

• Utilizando Test Driven Development TDD las pruebas son automáticas y autodocumentadas.

Herramientas

Existen en el mercado muchas herramientas que permiten realizar pruebas unitarias, la mas utilizadas son

Herramienta	Plataforma	Comentarios
NUnit http://www.nunit.org/	.Net Framework 1.0,1.1,2.0	Free, modo consola o interface gráfica
TestDriven http://www.testdriven.net/	.Net Framework1.0,1.1,2.0,3.0	Misma funcionalidad del NUnit como adin del VS.net.Los resultados se visulizan en modo texto en el VS.Net
JUnit http://www.junit.org/	Java	Stand alone o integrado a varios IDEs (Eclipse, java Builder etc)
vbUnit http://www.vbunit.com/	Visual Basic 6.0	Comercial, integrada con el VS VB 6.0
ASPUnit http://aspunit.sourceforge.net/	ASP.Net	Permite realizar casos de prueba para el front end de ASP.Net (proyecto open source suspendido)
TFS http://msdn.microsoft.com/en-us/teamsystem/default.aspx	.Net framework 2.0,3.0 y 3.5	Integrado con algunas versiones del Visual Studio Team System 2005/2008.
SoapUI http://www.soapui.org	Java	Permite ejecutar pruebas unitarias de consultas SOAP y REST.
SUNit http:\\sunit.sourceforge.net	Smaltak	El padre de todas las herramientas xUnit.

Conclusión

Las pruebas unitarias son un tema muy importante para garantizar la calidad del código que estamos creando. Usando una metodología de diseño y herramientas adecuadas este proceso se podría integrar para que en forma automática se ejecuten las pruebas unitarias ante cada subida al repositorio de código centralizado.Para ello se debería integrar con sistemas de control de versiones. Agregando un sistema de revisión de código automática junto se puede garantizar la alineación del código a estándares de codificación que mitigan problemas comunes de la aplicación de malas prácticas. Este tema está fuera del alcance del TDD pero si de las metodologías de desarrollo.

Referencias

1. Testing object-oriented systems: models, patterns, and tools, Addison-Wesley

2. Continuous integration, Martin Fowler, http://martinfowler.com/articles/continuousIntegration.html

3. Extreme Programming XP , http://xprogramming.com/index.php

4. Introducción a Scrum, http://www.mountaingoatsoftware.com/scrum

5. Agile Manifiesto, http://agilemanifesto.org/