A comenzar!
Hace unas horas mientras revisaba el Visual Studio 2010, encontré esta opcion, la cual no puedo dejar de comentar.

Cómo es que trabaja esta funcionalidad?
Pongámoslo de esta manera:
– Tenemos una serie de pruebas unitarias relacionadas a código que hemos construido.
– Hemos modificado parte del código que es verificado a traves de estas pruebas.
– Queremos saber que/cuales pruebas unitarias han sido afectadas.
– Es posible?

Bueno… lo es!
Comencemos con algo simple:
– Dos métodos con sus respectivos métodos de prueba
 

Creo que no hay necesidad de verificar que al ejecutar nuestros métodos de prueba, no tendremos problemas, es decir, todo en verde =)
Pero antes de hacer esto, vayamos a la ventana Test Impact View

Como podrán notar, es necesario habilitar este complemento, asi que, haremos click en Enable the test…

Procedemos a ejecutar nuestros métodos de prueba:
 

Hacemos un cambio en uno de los métodos, vamos, es un ejemplo, no sean tan exigentes =)

Luego del cambio podemos recompilar el proyecto, y vamos a la nueva ventana:
 

Como podrán notar, al realizar cambios en nuestro código fuente, la vista de impacto muestra (asi es) las pruebas unitarias que deberiamos revisar, o bueno, volver a ejecutarlas, cómo mínimo!!
Esto de por sí nos da una ayuda clave a nivel programación ya que –ahora si- no hay opción a decir “bueno, ya termine de programar, ahora a probar todo de nuevo! o por cual comenzar?”

Hasta aquí los invito a revisar el detalle de esta funcionalidad, pero para terminar quiero complementar con una opción adicional…

Se ubican en los métodos que van construyendo, hacen click derecho…
 

Favor notar que me he ubicado en un método que no ha generado impacto en las pruebas unitarias.

Los invito a revisar esta funcionalidad, espero les sea de utilidad.

Muchas Gracias.
@Jersson

Hola a todos,
Posiblemente, luego de haber ejecutado sus pruebas unitarias hayan encontrado la siguiente opción:

La cual muestra la cobertura del código realizada al momento de ejecutar las pruebas unitarias, es decir, ¿qué tanto código es cubierto por nuestras pruebas?

Pues bien, si queremos conocer esta información, click.

Si luego se encontraron con esto:
 
Al parecer falta configurar algo no? Asi es.

Veamos que pasos seguir.
Tal como indica la imagen, deben dirigirse a la opción
TestEdit Test SettingsLocal

Lo que encontrarán es la ventana principal de configuración de proyectos de prueba, la cual los invito a revisar de manera “curiosa”, por favor, sean cuidadosos =)
 
En la sección Data and Diagnostics, encontrarán la seccion de cobertura de código:


En este caso, lo que debe hacerse es dar click para habilitar dicha opción, y notar que el botón Configure ha sido habilitado.

Solo queda un paso, click en Configure.

Seleccionamos el assembly que necesitamos para cobertura de código, click en OK y Aplicar para regresar a nuestro Visual Studio.

Volvemos a correr nuestras pruebas

Al seguir estos pasos se encontrarán con:
 
Ahora, como podrán notar dice 50% de cobertura. Si desean cubrir un mayor %, digamos… 100% pues, se tendrían que programar muchas pruebas, para lo cual, lo recomendable sería automatizar o generar pruebas de una forma mas sencilla. Si están interesados en ese aspecto, los invito a revisar Microsoft Pex =D.

Sin más me despido.
Muchas Gracias

@Jersson

Comenzamos este post con una clase, digamos que “simple”. La cual refleja dos operaciones básicas; sumar y dividir.
Agreguemos a esto que la directiva de desarrollo es:
– “todo método va con su prueba unitaria”
Ante esto y ya lo he vivido en mas de un proyecto la respuesta común es:
– “me quita tiempo, lo dejaré para después, no es importante”
Entonces, solo me queda decir:
– “No hay pretexto que valga”

Esto por qué?
En primer lugar, no hay respuesta inválida, el problema es que muchas veces no hay un sustento concreto. Este es el caso de la frase “no es importante, me quita tiempo”, ya que, a pesar de ser cierto el hecho de tener que programar cada caso y prueba unitaria, es importante dejar este sustento.

Pero, el problema a relucir es muchas veces la cantidad de casos a probar y por ende, la cantidad de pruebas unitarias a preparar, vamos, tenemos que aceptar que el número de pruebas es variable. Dependiendo claro, de la lógica a ofrecer.
Tal es el caso de una división simple, que a pesar de tener dos parámetros, uno debe considerar aspectos importantes como el clásico caso de la división por cero.
Créanme, hay lugares donde he visto como se omitió esta variante y ERROR!!! LLAMEN A LOS BOMBEROS!! No es broma… pero bueno.

Entonces, si de división se trata, deberíamos tener al menos dos casos, o bueno, quizá mas… y ahora? a programar los casos? Nada que ver, usemos Microsoft Pex.
 

Esperamos mientras Pex comienza a revisar el método, hasta que muestra la siguiente ventana de resultados:

Aquí me detendré en algunas secciones de la ventana, como esta, que te indica los mensajes de las excepciones que saldrían si no controlamos bien nuestro código:
  

Si seleccionamos un registro, obtendremos información del método de prueba usado.
 

Por otro lado, en el extremo derecho de nuestro Visual Studio, encontraremos una nueva sección:
 
La cual nos dará una idea más gráfica del estado de los métodos de prueba generados.

Ahora!
Qué sucede si queremos tener estos métodos en un proyecto de pruebas?
Pues seleccionamos

Esperamos un momento y revisamos los cambios en nuestro Explorador de Soluciones:
 

Revisamos nuestro archivo vsmdi, el cual al abrir nos mostrará un listado de las pruebas unitarias creadas en toda la solución:

El cual será:

Ya si queremos verificar el estado de las pruebas unitarias, pues, check a todas, click derecho…

Si verificamos el resultado:

El cual es similar a lo obtenido inicialmente. Lo cual demuestra el traslado de las pruebas unitarias creadas de manera automática.

De por si, aquí hay mucho por ver, como por ejemplo el código generado, el cual, los invito a revisar =)
Me despido sin más, esperando sus comentarios, y claro, que descarguen y usen Microsoft Pex.

Saludos y Gracias
@Jersson

Buenos días =D
Hace poco mientras conversaba con unos amigos, y bueno, también en la ultima expo que tuve, mencioné esta funcionalidad UML.
De qué se trata? pues de momento, les comento algo que para muchos ya no es novedad, (de todas formas, espero darme un tiempo para el post) Visual Studio 2010 soporta UML 2.0
Como tal, podríamos dedicarle una serie de posts al respecto, como por ejemplo este enlace, que ubiqué sin muchos problemas en la red.

Pero bueno, la idea del post es mostrarles como es que se puede aprovechar la ingeniería reversa del Visual Studio 2010, y con esto (y un poco de suerte) generar un diagrama de secuencia. Debemos admitirlo, todos hemos pasado por la clásica pregunta ¿y los diagramas?

Bien, comenzamos con dos clases en una Biblioteca de Clases (si El Bruno dice que asi se llama, en mas de uno de sus posts, es cierto!)

Como podrán notar se trata de una clase con el objetivo particular de administrar entradas y salidas de stock, digamos que estamos manejando un almacén tradicional, en el cual se administran cierta cantidad de items.

Entonces, hemos creado un formulario que simula este tipo de movimientos (ingreso, salida y ver el disponible), es decir:
(no, no tengo plug-ins de código fuente =D)

Bien, aqui la interrogante… UML??? si, es factible. Facil, click derecho…
 

Configuración de las llamadas incluir (los invito a revisar esta ventana)

Ingeniería reversa en progreso!

Y luego…

Diagrama de secuencias =)

Si hay algo mas para mostrar? pues la verdad, mucho… pero de momento, me despido no sin antes recomendar revisen su Visual Studio, queda mucho por aprender =)

Saludos
@Jersson

Hola a todos, aquí algo para compartir, lo dejaré en imágenes, ya que la clave principal es ubicarte sobre la pestaña del archivo en que te encuentres trabajando, luego, arrastrar y soltar!

Dentro del Visual Studio

O bueno, si desean, fuera del mismo.

 
Sin más me despido.
Saludos y si tiene dos monitores, me avisan!
@Jersson