Usamos o Selenium para testar a camada de interface do usuário do nosso aplicativo ASP.NET. Muitos dos casos de teste testam fluxos mais longos que abrangem várias páginas.

Descobri que os testes são muito frágeis, quebrados não apenas por alterações de código que realmente alteram as páginas, mas também por refatorações inócuas, como renomear um controle (já que preciso passar o clientID do controle para o método Click do Selenium, etc.) ou substituindo um gridview com um repetidor. Como resultado, eu estou perdendo tempo atualizando os valores das strings nos meus casos de teste para corrigir testes quebrados.

Existe uma maneira de escrever testes de selênio mais sustentáveis? Ou uma melhor ferramenta de teste de interface do usuário da web?

Editado para adicionar: Geralmente, o primeiro rascunho é criado gravando um teste no IDE. (Essa primeira etapa pode ser executada pela equipe de controle de qualidade.) Depois refatoro o código C # gerado (extrair constantes, extrair métodos para código repetido, talvez repetir o caso de teste com dados diferentes, etc.). Mas o fluxo geral de código para cada caso de teste permanece razoavelmente próximo do código gerado originalmente.