3 jul 2010
¿Cuales son las caracteristicas de una buena Prueba Unitaria?
iremos tocando poco a poco hasta cubrir todas sus aristas.
¿Cuales son las caracteristicas de una buena Prueba Unitaria?
1- Debe ser automatizada y repetible.
2- Debe ser fácil ejecutar.
3- Una vez que ha escrito, debe permanecer para el uso futuro.
4- Cualquier persona debe poder ejecutarlo.
5- Debe ejecutarse con el click de un botón.
6- Debe ejecutarse rápidamente.
Mucha gente confunde el acto de probar su software con el concepto de una prueba unitaria
Ejemplo de una simple test unitario:
Es posible escribir una prueba unitaria automatizada sin usar un Framework de prueba (Nunit).
Asumimos que tenemos una clase SimpleParser (mostrada ).
Tiene un método llamado "ParseAndSum" de el cual admita una cadena
de 0 o más números separados por comas. Si no hay números, vuelve 0. Si hay un solo número,
retorna ese número como int. Si hay números múltiples, los agrega todos para arriba y
retorna la suma (aunque, ahora, el código puede manejar solamente 0 o 1 número).
public class SimpleParser
{
public int ParseAndSum(string numbers)
{
if(numbers.Length==0)
{
return 0;
}
if(!numbers.Contains(","))
{
return int.Parse(numbers);
}
else
{
throw new InvalidOperationException(
"I can only handle 0 or 1 numbers for now!");
}
}
}
Podemos crear un proyecto de aplicación simple de consola que tenga una referencia al assembly que contiene esta clase,y podemos escribir un método " SimpleParserTests" según se muestra.
El método de la prueba invoca la clase de la producción (la clase que se probará) y después controla el valor devuelto. Si no es la que se espera, se escribe a la consola.
También coge cualquier anomalía y la escribe a la consola.
class SimpleParserTests
{
public static void TestReturnsZeroWhenEmptyString()
{
try
{
SimpleParser p = new SimpleParser();
int result = p.ParseAndSum(string.Empty);
if(result!=0)
{
Console.WriteLine(
@"***SimpleParserTests.TestReturnsZeroWhenEmptyString:
-------
Parse and sum should have returned 0 on an empty string");
}
}
catch (Exception e)
{
Console.WriteLine(e);
}
}
}
Después, podemos invocar los test que hemos escrito usando un método Main simple dentro de una aplicación de la consola. El método Main se utiliza aquí como ejecutor de la prueba simple,
que invoca las pruebas uno por uno, dejándolas poner a la consola.
Porque es una ejecutable, esto se puede ejecutar sin la intervención humana.
public static void Main(string[] args)
{
try
{
SimpleParserTests.TestReturnsZeroWhenEmptyString();
}
catch (Exception e)
{
Console.WriteLine(e);
}
}
Es responsabilidad del método de prueba coger cualquier anomalía que ocurra y escribierla a la consola, de modo que ella no interfiera con ningun funcionamiento de métodos subsecuentes.
Podemos entonces agregar más llamadas al método en el método Main como agregamos cada vez más pruebas al proyecto. Cada prueba es responsable de escribir el problema (si hay un problema) en la pantalla de la consola.
23 ene 2010
Virtualizando las aplicaciones .NET, Java, etc
Tiene un comodo Wizard que guia la configuracion del nuevo executable portable, especificando files, framework's, ETC; ademas de especificar si se ejecutara desde un USB, host, etc.
descargalo aqui:
http://rapidshare.com/files/149488878/Xenocode_Virtual_Application_Studio_2008.6.1.261.rar
3 ene 2010
Como reproducir un archivo Wav con .Net 3.5
EL Problema
Se necesita reproducir un fichero de WAV.
Crear una nueva instancia de la clase System.Media.SoundPlayer, pasar la localización o stream del fichero WAV, e invocar al método Play.
Cómo Hacerlo
El namespace System.Media, fue introducido en el Framwork 2.0 de .NET, contiene una clase SoundPlayer.
SoundPlayer contiene constructores que le dejan especificar la localización de un fichero de WAV o su stream. Una vez que se ha creado una instancia, solo se necesita invocar al método Play para reproducir el archivo. El método Play crea un nuevo thread para reproducir el sonido y es de esta manera asíncrona (a menos que utilice un stream).
Para reproducir el sonido de manera síncrona, utilizar el método de PlaySync. Notar que SoundPlayer utiliza solamente el formato de WAV.
Antes de que se reproduzca un fichero, se carga en memoria. Usted puede cargar un archivo por adelantado invocando el método Load o LoadSync, dependiendo de si usted quisiera que la operación fuera asíncrona o síncrono.
El Codigo
Imports System
Imports System.Windows.Forms
Imports System.Media
Partial Public Class Ejemplo
Private Sub cmdOpen_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdOpen.Click
' Allow the user to choose a file.
Dim openDialog As New OpenFileDialog
openDialog.Filter = "WAV Files|*.wav|All Files|*.*"
If openDialog.ShowDialog = Windows.Forms.DialogResult.OK Then
Dim player As New SoundPlayer(openDialog.FileName)
Try
player.Play()
Catch ex As Exception
MessageBox.Show("An error occurred while playing media.")
Finally
player.Dispose()
End Try
End If
End Sub
End Class
30 dic 2009
Conversor online de VB a C#
Pues este aplicativo convierte rapidamente todo el codigo que se le solicite.
Disponible en el Toolbox del sitio developerFusion, pruebalo Aqui
Esta basado en el proyecto #develop editor, alternativa free open source al Visual Studio .NET de Microsoft; ademas de soportar sintaxis de para NET 3.5 y NET2.0 .
28 dic 2009
Arquitecturas empresariales de soluciones .NET
Que es una Arquitectura de Software?
La arquitectura es el esqueleto de un sistema, el conjunto de pilares que soportaran la construcción, para eso el arquitecto debe ser multifacético, conocer sobre requerimientos, diseño de sistemas, garantizar que la implementación satisfaga las expectativas y asegurarse globalmente que los usuarios obtengan lo que realmente necesitan, el cual no es necesariamente lo que inicialmente aceptaron y pagaron.
La arquitectura de software tiene precondiciones ( principios de diseño )
El rol de un arquitecto es primeramente responsable por el conocimiento de requerimiento, diseño del sistema, y comunicación del diseño al equipo de desarrollo.
La comunicación esta a menudo basada en bosquejos UML.El arquitecto aplica primero principios generales de ingeniería de software, después principios de diseño orientado a objetos, para romper el sistema dentro de pequeñas piezas en un intento de separar que es arquitectura y que no. Uno de los propósitos del diseño orientado a objetos es hacer tu código fácil de mantener y desarrollar- y también fácil de leer y entender.
El arquitecto conoce el mantenimiento, seguridad y las pruebas necesarias a ser incluidas al sistema desde el comienzo.
Conocerás la perfección del diseño, no cuando no tengas algo que agregar, sino cuando no tengas nada que quitar.
El propósito de
Dr Pamela Zave
¿Qué es una arquitectura de Software, en todo caso?
Herman Melville, el autor inolvidable de Moby Dick, alguna vez dijo que los hombres piensan que articulando palabras duras pueden entender cosas duras.
En software, la “dura” palabra Arquitectura fue introducida originalmente en este campo para simplificar la transmisión y la comprensión de una clave y ” dura” guía de consulta.
La guía de consulta era ésta: Más (mucho) cuidado sobre el diseño de sistemas informáticos que comprendías en el pasado; cuidado con esto al punto de dirigir el desarrollo de un sistema informático de forma similar a dirigir el desarrollo de un edificio.
Definición de sistema desde un punto de vista estándar
Un sistema informático se entiende universalmente como una colección de componentes compuestos e integrados para lograr un conjunto específico de funciones.
Un sistema vive en un entorno; y este entorno influye al diseño del sistema conduciendo a algunas decisiones de desarrollo y operacionales. Un sistema existe para solucionar un problema y para alcanzar su misión completamente respecto a lo concerniente de los "Stakeholders". Todo lo concerniente de los "Stakeholders" incluyen requisitos funcionales y no funcionales así como aspectos del sistema tales como seguridad, posibilidad de prueba, funcionamiento, confiabilidad, y extensibilidad.
Aunque prevea al sistema como una composición de componentes interconectados, una arquitectura también establece algunos puntos que son duros de modificarse más adelante.
De manera que, la expresión del desarrollo de software en términos de arquitectura concluye en la generacion de algunas decisiones importantes que afectan el ciclo vital del desarrollo y, en última instancia, a la calidad del sistema resultante.
El cuadro 1 ilustra los lazos entre el sistema, la configuración, y los "Stakeholders" según lo identificado por el estándar 1471 de ANSI/IEEE. El contenido del cuadro 1-1 es realmente una adaptación de una de las figuras en el documento.
27 dic 2009
Procesos del testing de un software
El proceso para testear bloques de la aplicación se muestran abajo. Los pasos listados deberan ser utilizados independientemente de la metodologia de testing.
Entrada de información (Input's)
La entrada de información siguiente se requiere para testear una aplicación:
- Especificaciones funcionales
- Requerimientos
- Objetivos de funcionamiento
- Escenarios de despliegue
Pasos
El cuadro muestra los pasos en el proceso de testing para una aplicación.
- Crear los planes de prueba.
- Revizar el diseño.
- Revisar la implementacion.
- Realizar la prueba de la caja negra.
- Realizar la prueba de la caja blanca.
Paso 1: Crear los planes de prueba
Los planes de prueba documentan los Casos de Prueba que usted utilizará para testear la aplicación. Los casos de prueba cubren todos los aspectos de la prueba, incluyendo la revisión de diseño, la revisión de código, el profiling, la prueba del despliegue, y la prueba de carga. Los planes de prueba ayudan a asegurarse de que usted pruebe todas las características y escenarios de uso de una aplicación.
La documentación del plan de prueba consiste en dos documentos:
El documento del plan de prueba detallado (DTP) .
El documento detallado del plan de prueba enumera los casos de prueba en una orden prioritaria (Alta, media, y baja). Las descripciones del caso de prueba en este documento resumen abreviadamente los escenarios de uso y las características que se testearan. Para cada caso de prueba, usted asigna un nivel de prioridad basado en la importancia del caso y su impacto total del caso en las metas a cumplir, planeadas estas por los objetivos y los requisitos deseados.
El documento de casos de prueba detallado (DTC).
El documento de casos de prueba detallados asocia al documento detallado del plan de prueba. Este documento describe los pasos que el usuario debe realizar para ejecutar cada caso de prueba que este listao en el documento DTP. También enumera los datos que se requiriran para la prueba y describe los resultados previstos de esta prueba.
Se actualizaran los documentos DTP y DTC a través del ciclo de vida del desarrollo. Por ejemplo, usted debera actualizar estos documentos si las especificaciones funcionales o los requisitos cambian, o si usted tiene una información (input) adicional. Usted también los actualizara si agrega más adelante en el ciclo del desarrollo casos de prueba o si modifica la prioridad de los casos de prueba existentes a razon de escenarios de usos o pruebas funcionales adicionales .

