Testando seu código programaticamente: pelo programador ou por outra pessoa?

Question

Então, aqui está a situação- uma citação do meu chefe: [...] Precisamos nos concentrar na programação. [...] No final do dia, quero escrever um bom software e não ficar atolado em testes . " Isso é dito depois de termos três meses de uma lista assustadora de bugs e recentemente designando um não programador para escrever testes da Web com a estrutura de Selenium.

Meu chefe é muito tímido (ele não pode ver o custo-benefício quando diminui os desenvolvedores). Quais são suas opiniões por aí em testes da Web e testes programáticos em geral? Eles devem ser escritos pelo programador (ou a) ou isso importa? Meu pensamento foi que parte da redação de bons softwares está escrevendo testes? Ele é um tipo de cara de torre de marfim da Microsoft e, portanto, quaisquer recursos por aí que foram divulgados pela Microsoft (ou bons artigos em geral) em favor dos testes por design seria útil.

Answer 1

Aqui está o que eu fiz.

1. Eu escrevi os testes de qualquer maneira.

2. Eu escrevi o código depois de escrever os testes.

3. O código era sólido e (principalmente) sem insetos (para os limites das minhas habilidades.)

Eu nunca disse a ninguém que estava fazendo TDD. A menos que eles perguntem.

Acontece que o TDD é realmente mais rápido do que mexer tentando projetar algo, codificá -lo e espero que funcione.

Algumas coisas incluem uma etapa extra 0: um "pico de tecnologia" para ver como as coisas funcionam. Isso é seguido por algum desenvolvimento de teste para exercer o software real ainda não escrito.

Estou um pouco atrasado quando se trata de iniciar o design. Como meu design é "Design e escreva testes para esse design", enquanto outras pessoas designam "se arranham com algumas idéias inteligentes, mas sem provas reais". Algumas pessoas podem projetar bem no papel. Não posso. Mas eu posso projetar testes.

Geralmente estou muito à frente quando se trata de terminar o código. Desde - quando terminei a codificação - todos os testes passam.

Answer 2

O código completo é um livro que faz parte da coleção da Microsoft. Ele contém conselhos que defendem a revisão de pares e a escovação após o teste de unidade como um conceito. Ele não vai muito longe em detalhes com testes de unidade, mas pode aquecê -lo até a idéia e você pode explorar ainda mais o tópico a partir daí.

Por fim, você precisa de alguém que seja um programador diretamente envolvido na automação de testes ... quero dizer, isso é por definição.

Os testes de unidade são escritos de maneira mais eficaz pelas pessoas mais familiarizadas com os subsistemas em que estão escritos, quando alguém é escolhido para escrever testes de unidade que levam tempo para aumentar, e podem perder a intenção não documentada ou clara no código o que pode resultar em pior cobertura. Por outro lado, o proprietário do subsistema também pode ser cego para certas deficiências (mas é para isso que servem as revisões de código de pares!)

---

O resto disso é realmente apenas uma discussão ociosa sobre ética, mas é importante considerar.

Algumas pessoas gostam de tentar e "esgueirar -se" para a construção quando a gerência toma decisões tolas. Isso me deixa não apenas desconfortável, mas também meio cauteloso com esses programadores. Entendo a motivação, acho que todos estivemos lá, mas, em última análise, você deve educar, em vez de participar de subterfúgios.

A gerência desempenha um papel importante na programação e eles dependem de você para estimativas precisas e um entendimento geral do trabalho que está sendo realizado. Se você acertar suas estimativas para varrer o trabalho extra debaixo do tapete, isso é realmente uma coisa boa? O que foi uma mentira simples se torna essa farsa elaborada que você está jogando nas pessoas envolvidas diretamente em ajudar sua carreira a progredir.

O que foi um problema com processo e estimativa para o trabalho legítimo agora se tornou uma questão de ética pegajosa.

Eu recomendo fortemente seguir sua abordagem planejada de convencer seu gerente a ver seu ponto de vista por meio da razão, lógica e apelar ao seu amor pela Microsoft. ;)

A longo prazo, se você se encontrar constantemente combatendo a gerência em decisões sobre o processo de programação (que realmente não é o trabalho deles para tomar decisões), provavelmente seria melhor polir esse currículo e encontrar um emprego melhor.

Parte do trabalho de um programador é educar as pessoas envolvidas que têm menos experiência. Explicar isso ao seu gerente pode ajudar a dividir algumas das barreiras intelectuais que ele tem sobre o assunto e o amoleceu a aceitar seus conselhos sobre o assunto.

Answer 3

Eu vou ao mundo que, para que algo seja "feito", precisa ter sido verificado por pelo menos duas pessoas. Você nem sempre precisa de um testador de software na equipe se todos da equipe acreditarem que a qualidade do software é o trabalho de todos.

Se você deseja que seja altamente eficiente, o desenvolvedor que escreve o código deve estar escrevendo os testes e alguém os revisa com o código de produção. Se você deseja ser altamente eficaz, emparelhar -se com alguém e eles escrevem os testes enquanto escreve o código em um "TDD emparelhado".

Lembre ao gerente de que o custo dos bugs cresce expectativa no posterior que é encontrado.

Answer 4

Eu entendo de onde seu chefe está vindo. Afinal, os programadores devem ser capazes de produzir código que apenas "funciona". No entanto, testes vai Acontece, não importa o quê, seja testando de unidade, teste de integração em sua empresa ou depois de instalar no cliente. Erros em cada um desses estágios têm custos e consequências diferentes, no entanto ...

Answer 5

Você costuma ouvir que é uma boa ideia fazer com que outras pessoas testem seu código, porque elas podem interpretar a especificação de maneira diferente. No entanto, o benefício de escrever os testes para seu próprio código é que você sabe onde ele pode estar com defeito.

Uma abordagem eficiente pode ser uma mistura de ambos: o programador escrevendo seus próprios testes de unidade, focando nos casos de canto e alguém fazendo alguns testes funcionais, concentrando-se na especificação de nível superior.

Answer 6

Nem todos os testes são criados iguais, vamos analisar alguns:

• Testes de unidade / TDD. É difícil argumentar contra, especialmente como o contrário de "ele não pode ver o custo -benefício quando diminui os desenvolvedores", é mais rápido. S. Lott passa pelos detalhes.
• Testes de integração focados. O mesmo que acima, é mais rápido. Não há que passar por uma série de etapas através do seu aplicativo totalmente integrado, para descobrir se essa camada muito fina de código de integração que você acabou de escrever está funcionando. É o pior quando você considera repetido o que você precisa entrar lá, e ainda mais quando se torna fortemente acoplado a diferentes processos.
• Testes completos do sistema. Com o exposto acima, você só quer saber se todas as peças foram conectadas corretamente e se a interface do usuário está funcionando como esperado. Para o anterior, você precisa de uma pequena quantidade de testes que são escritos muito rapidamente; Compare isso com quantas vezes as pessoas passam manualmente (incluindo você) e você terá um vencedor :). Para o posterior, existem algumas coisas difíceis de capturar com testes automatizados, para que você não concentre a automação nelas.
• Testes exploratórios. Eles ainda devem ser feitos, espero que seja o pensamento suficiente antes que o recurso seja construído para evitar ter que fazer alterações extras neste momento.

Agora, o controle de qualidade geralmente apresenta cenários adicionais. Isso é bom, mas é o melhor quando está incluído de maneira colaborativa nos testes automatizados.

Um problema real pode ser as habilidades atuais da equipe. O teste de unidade é mais difícil, quanto mais acoplado o código é, isso geralmente é pior com o código existente sem testes de unidade, mas também inicialmente dificulta a avanço de um desenvolvedor que não sabe bem como projetar código livremente acoplado/alto Código de coesão. Ele precisa ser feito, mas esteja ciente disso, pois o custo vai para algum lugar (para os membros da equipe ou a empresa).

Answer 7

Para criar uma boa suíte de teste, é preciso um pouco de esforço; Isso levará mais tempo do que o esperado.

A esse respeito, seu chefe está certo.

No entanto, se você planeja estender seu produto (adicionar recursos) ou site (adicione páginas e código JavaScript), você precisará criar a suíte de qualquer maneira posteriormente.

Answer 8

Você pode ressaltar que teste de unidade é incorporado na estrutura do .NET desde o VS2005.