domingo, 24 de marzo de 2013

Instalando GIT en distribuciones Fedora


Estaba tratando de instalar GIT en una máquina virtual que me descargué con sistema operativo Linux basado en Fedora. Cuando corría el comando:

$ yum install git

me daba el siguiente error:

yum No package git available.

Despues de buscar un rato por Internet encontré que hay que descargar el repositiorio EPEL (Extra Packages for Enterprise Linux)

sudo rpm -Uvh http://mirrors.ucr.ac.cr/epel/5/i386/epel-release-5-4.noarch.rpm

La URL de arriba es la de un mirror de la Universidad de Costa Rica puesto que es el mirror más cercano que encontró. Si no hace conexión es cuestión de buscar otro que esté activo.

Listo. Se vuelve a ejecutar el comando YUM y esta vez sí debería funcionar.



jueves, 14 de marzo de 2013

Oracle Drop Schema

La manera en que uno borra una base de datos en Oracle (típico DROP SCHEMA), o al menos la forma que conozco, es borrando el usuario dueño del esquema con la opción de cascada:

sqlplus "/ as sysdba";
SQL> drop user user_name cascasde;

Oracle: Importar/Exportar un dump


Una actividad muy recurrente cuando se manejan bases de datos es la de exportar algún esquema para respaldar la base de datos, y luego importarla para restaurar un esquema a un estado en particular.

En Oracle esto se puede hacer desde la línea de comandos usando "expdp" y "impdp" para exportar un dump e importar un dump.

expdp db_user/db_pass schemas=schema_name dumpfile=file_name.dmp
impdp db_user/db_pass schemas=schema_name dumpfile=file_name.dmp

El comando exporta el dump en el path donde está instalado el Oracle. En mi caso lo tira en este directorio:

/usr/lib/oracle/xe/app/oracle/admin/XE/dpdump/

A la hora de importarlo hay que colocarlo ahí tambien puesto que el comando no permite indicar el path  en el parámetro del archivo.

lunes, 4 de marzo de 2013

Tests de Unidad, Integración y Funcionales


Parece existir cierto grado de confusión entre los desarrolladores a la hora de referirse a los conceptos de tests de unidad, integración y funcionales. De hecho eso estababa sucediendo en mi trabajo, así que me hice a la tarea de investigar alguna autoridad en el campo que definiera de manera clara estos conceptos, y de esta forma que no quedara como una opinión más de la Internet.

Para estos fines encontré el libro escrito por Gerard Meszaros: 
















Tests de Unidad


Los tests de unidad verifican el comportamiento de una sola clase o método que es consecuencia de una decisión de diseño. Este comportamiento está típicamente no directamente relacionado a los requerimientos, excepto cuando un pedazo clave de la lógica de negocio está encapsulado dentro de la clase o el método en cuestión. Estos tests son escritos por los desarrolladores para su propio uso; estos ayudan a los desarrolladores a describir cómo "luce lo que está hecho" al resumir el comportamiento de la unidad en forma de tests.

Tests de Integración/Componente


Los tests de componente verifican los componentes que consisten en un grupo de clases que colectivamente proveen un servicio. Estos se localizan entre los tests de unidad y los tests de cliente en términos del tamaño del SUT (System Under Tests/Sistema Bajo Prueba) siendo verificado. Aunque algunas personas llaman a estos "tests de intregración" o "tests de subsistema", estos términos pueden significar algo enteramente diferente de "tests para un subcomponente específico largamente granulado del sistema entero".

Tests Funcionales/Cliente

Los tests de cliente verifican el comportamiento del sistema entero o de la aplicación. Tipicamente corresponden a escenarios  de uno o más casos de uso, características, o historias de usuario. Estos test muchas veces son referidos por otros nombres como tests funcionales, tests de aceptación, o tests de usuario final. Aunque muchas veces pueden estar automatizados por desarrolladores, su característica principal es que un usuario final debería ser capaz de reconocer el comportamiento especificado por el test aún cuando el usuario no pueda leer la representación del test.




Figura: Un resumen de los tipos de tests que escribimos y por qué. La columna de la izquierda contiene los tests que escribimos que describen la funcionalidad del producto a varios niveles de granularidad; ejecutamos estos tests para apoyar al desarrollo.
La columna de la derecha contiene los tests que abarcan pedazos específicos de funcionalidad; ejecutamos estos tests para criticar el producto. Al final de cada celda se describe qué se intenta comunicar o verificar.