escribí un post sobre cómo hacer esto le puede resultar útil
http://rburnham.wordpress.com/2011/03/15/bdd-ui-automation-with-specflow-and-coded-ui-tests/
Los pros y los contras de Coded prueba de interfaz de usuario que se me ocurre es el de probar la aplicación exactamente cómo el usuario se estar usándolo. Esto es bueno para la prueba de aceptación, pero también tiene sus limitaciones. También es muy bueno para las pruebas de extremo a extremo. En el pasado, las pruebas de UI se han sabido frágiles. Por ejemplo, cuando MS creó la interfaz de usuario VS2010, casi todas las pruebas de UI se rompieron. La razón principal es el cambio tecnológico. Las pruebas de IU codificadas ayudan a limitar que esto suceda por la forma en que coincide con un control. Utiliza más de una coincidencia basada en la probabilidad. Esto significa que intentará encontrar la mejor coincidencia basada en la información que tiene, como el nombre del control. Para nosotros, las pruebas de IU codificadas fueron nuestra elección debido a las limitaciones de la tecnología. Nuestra aplicación Legacy es VB y aunque CUIT no funciona muy bien, estoy en el proceso de escribir una extensión para obtener una mejor información de control, todavía era nuestra única opción. También tenga en cuenta que CUIT es nuevo y tiene sus propias limitaciones. Debe estar preparado para estar muy estructurado en la forma en que diseña su proyecto, ya que mantener su UIMaps puede ser un poco trabajo manual debido al comportamiento actual de extremo a extremo en VS2010, por ejemplo, crear un CUIT a partir de una acción existente la prueba en un UIMap llamado UIMap.uitest y no hay forma de cambiar eso o transferirlo a otro UIMap. Si usa múltiples mapas de ui, esto significa que primero tendrá que registrar sus pasos y luego usarlos en su prueba. Sin embargo, al estar en .net, sigue siendo muy flexible.
De lejos, lo mejor del flujo de especificaciones es su sintaxis gerkin para la legibilidad y la documentación de vida. Normalmente sus características o comportamientos de prueba de su aplicación, de donde proviene el valor, generalmente apuntan a la prueba justo debajo de la IU. Hay menos posibilidades de que se rompa la prueba cuando la IU cambia aquí pero allí. Specflow para mí es excelente cuando su aplicación está en constante cambio y desea asegurarse de que las funciones existentes sigan funcionando. También se adapta bien en un entorno de Scrum donde puede escribir su escenario como una descripción sobre cómo debería funcionar. Una limitación para el flujo de especificaciones que puedo ver es que está abierta para la interpretación. Debido a esto, puede ser fácil escribir una prueba que no sea muy reutilizable y difícil de mantener. Me gusta utilizar términos más genéricos para describir mis pasos, como "Iniciar sesión como Usuario1" en lugar de "Ir a la página de inicio de sesión, Ingresar nombre de usuario y contraseña, Hacer clic en Iniciar sesión". Al describirlo de forma más granular, es más difícil reutilizarlo fuertemente que lo empareja con la IU. Cómo funciona realmente el inicio de sesión debe corresponderse con el código que está detrás, no con la función de flujo de especificaciones.
Sin embargo, la combinación de 2 nos parece más beneficiosa que el simple uso de las pruebas de interfaz de usuario codificadas. Si decidimos cambiar por completo la interfaz de usuario, al menos tendremos los comportamientos que esperamos que estén almacenados en nuestras características de flujo de datos de una manera que todos puedan entender. Al final, debe considerar cómo evolucionará la aplicación y el tipo de aplicación.