Testes RSpec + Selenium para .NET no Windows

Sou desenvolvedor de Rails que faz TDD em um Mac com o RSpec, Capybara e Selenium. Agora, minha empresa me pediu para usar essa abordagem em um ambiente .NET no Windows. Qual a melhor maneira para fazer isto?

Eu poderia apenas instalar o Ruby e usar o webdriver RSPEC, Capybara e Selenium para testes de integração. Mas e os testes de unidade? Eu também olhei para o NSpec , mas não sei se posso combinar isso com Capybara ou Selenium para testes de integração.

Qual seria uma boa abordagem aqui?

Este é um problema em duas partes.

Em termos de testes funcionais / de integração nos quais você está dirigindo o software externamente, qualquer uma das abordagens é válida; a consideração aqui é o conjunto de habilidades daqueles que criam e mantêm os testes. Em termos gerais, vejo uma tendência à familiaridade com a linguagem usada para ferramentas (teste / compilação / qualquer que seja) como sendo a coisa mais importante se você não quiser acabar com um especialista em domínio único do qual a equipe depende.

No entanto, para testes de unidade, deve ser algo que funcione no ambiente de desenvolvimento .NET - xUnit (ou nUnit, mas eu prefiro o xUnit) é a opção "convencional", mas não vejo razão para não usar o NSpec.

Se você deseja acessar todo o .NET, o Coypu foi inspirado na Capivara

Eu abandonaria o Ruby e utilizaria o nUnit, SpecFlow e Selenium WebDriver para testes de unidade, integração e interface do usuário se o produto estivesse escrito em .net. Além disso, eu trocaria o mac por uma máquina Windows.

Sei que é possível misturar idiomas e plataformas, e escrevi testes em ruby ​​para produtos .net. Mas é um pouco mais fácil se você usar a mesma pilha para tudo.

Você pode adicionar seus projetos de teste à mesma solução e afastar tudo do mesmo processo de compilação. Os desenvolvedores poderão executar os testes no visual studio com apenas alguns cliques. Além disso, é uma nova habilidade no seu currículo.

Mas, principalmente, não se preocupa em ter que instalar os produtos extras, encontrar os bits e bobs de terceiros que eles os fazem tocar juntos e manter um processo de IC complicado.