Pruebas de RSpec + Selenium para .NET en Windows

Soy un desarrollador de Rails haciendo TDD en una Mac con controlador web RSpec, Capybara y Selenium. Ahora mi compañía me ha pedido que use este enfoque para un entorno .NET en Windows. Cual es la mejor manera de hacer esto?

Podría instalar Ruby y usar el controlador web RSPEC, Capybara y Selenium para las pruebas de integración. ¿Pero qué pasa con las pruebas unitarias? También miré a NSpec , pero no estoy seguro si puedo combinar eso con Capybara o Selenium para las pruebas de integración.

¿Cuál sería un buen enfoque aquí?

Este es un problema en dos partes.

En términos de pruebas funcionales / de integración en las que está manejando el software externamente, cualquiera de los enfoques es válido, la consideración aquí es el conjunto de habilidades de aquellos que crean y mantienen las pruebas. En términos generales, veo una tendencia a la familiaridad con el lenguaje utilizado para las herramientas (prueba / compilación / lo que sea) como lo más importante si no desea terminar con un solo experto de dominio del que depende el equipo.

Sin embargo, para las pruebas unitarias tiene que ser algo que funcione dentro del entorno de desarrollo .NET: xUnit (o nUnit, pero prefiero xUnit) es la opción "convencional", pero no veo ninguna razón para no usar NSpec.

Si quieres ir a .NET, Coypu se inspiró en Capybara

Abandonaría a Ruby e iría con nUnit, SpecFlow y Selenium WebDriver para pruebas de unidad, integración y UI si el producto está escrito en .net. Además, cambiaría la mac por una máquina con Windows.

Sé que es posible mezclar idiomas y plataformas, y he escrito pruebas de ruby ​​para productos .net. Pero es un poco más fácil si usas la misma pila para todo.

Puede agregar sus proyectos de prueba a la misma solución y eliminar todo el proceso de compilación. Los desarrolladores podrán ejecutar las pruebas desde el estudio visual con un par de clics. Además, es una nueva habilidad en tu CV.

Pero principalmente no tiene que preocuparse por tener que instalar los productos adicionales, encontrar los bits y bobs de terceros que los hacen jugar juntos y mantener un proceso de CI complicado.