Com que frequência você executa e testa seu código durante a programação? [fechadas]

Especialmente ao escrever um novo código do zero em C, eu me pego escrevendo código por horas, até dias sem executar o compilador para qualquer coisa, exceto uma verificação ocasional de sintaxe.

Costumo escrever pedaços maiores de código com cuidado e testar completamente somente quando estou convencido de que o código faz o que deveria fazer analisando o fluxo na minha cabeça. Não me interpretem mal - eu não escreveria 1000 linhas sem testar (isso seria um jogo), mas escreveria uma sub-rotina inteira e a testaria (e corrigi-lo se necessário) depois que eu terminar.

Por outro lado, vi principalmente novatos que executam e testam seu código após cada linha que entram no editor e pensam que os depuradores podem substituir o cuidado e a sanidade. Considero isso uma grande distração depois que você aprendeu a sintaxe do idioma.

Qual você acha que é o equilíbrio certo entre as duas abordagens? É claro que o primeiro exige mais experiência, mas isso afeta a produtividade positiva ou negativamente? O segundo ajuda a detectar erros em um nível mais preciso?

REALMENTE depende do aspecto do projeto em que você está trabalhando.

• Quando faço qualquer coisa com o OpenGL (que funciona como uma máquina de estado), constantemente compilo e corro para garantir que não estraguei nada acidentalmente. Definir um valor sem lembrar de redefini-lo no final de uma função pode facilmente tornar o aplicativo renderizado apenas uma tela preta.

• Para um desenvolvimento em grande escala "sob o capô", tento fazer o maior número possível de testes com antecedência. Como os testes podem me dizer com mais facilidade o que ocorreu, posso demorar um pouco sem ter que esperar pela compilação normalmente longa.

• Para o design de UX, eu uso algum tipo de designer visual, que sempre parece com o modo como será executado (ou próximo a ele). É essencialmente sempre compilando o código de design.

Pessoalmente, preciso trabalhar em pequenos pedaços, porque não sou inteligente o suficiente para manter horas de codificação no meu cache biológico L1. Devido às minhas capacidades limitadas, escrevo métodos pequenos e coesos e objetos de design para ter um acoplamento muito frouxo. Ferramentas e linguagens mais poderosas facilitam a codificação por mais tempo sem criar, mas ainda há um limite para mim.

Minha preferência é escrever um pequeno pedaço, verificar se funciona como eu esperava. Então, em teoria, sou livre para esquecer os detalhes dessa peça e tratá-la como uma caixa preta o máximo possível.

Eu gosto de escrever meu teste antes de escrever meu código de implementação. Eu gosto disso por três razões:

1. Escrever meu código de teste antes da mão me ajuda a pensar em como meu código deve ser usado. Isso me ajuda a pensar em casos extremos que eu não pensava quando estava originalmente projetando meu programa.
2. Sei que terminei de escrever o código de implementação quando todos os meus casos de teste foram aprovados.
3. Adquirir o hábito de escrever testes antes do código também tem o efeito adicional de provar que seu código não adicionou novos bugs (supondo que você tenha escrito bons casos de teste).

Eu me pego escrevendo código por horas, mesmo dias, sem executar o compilador para nada além de uma verificação de sintaxe ocasional.

Horas a dias - é um sinal claro de que você perde a capacidade de dividir seu código em blocos menores que podem ser verificados e testados por conta própria. Você definitivamente deveria trabalhar nisso.

Costumo escrever pedaços maiores de código com cuidado e testar completamente somente quando estou convencido de que o código faz o que deveria fazer analisando o fluxo na minha cabeça.

Em vez de escrever pedaços de código maiores - e, portanto, complicados - que precisam de horas para serem analisados ​​em sua cabeça, você deve tentar criar blocos de construção menores, não tão grandes. Isso se chama construção de abstrações - e essa é a essência da boa programação, definitivamente não é um sinal de ser um novato.

Uma excelente programação é como uma excelente jogada de Billard - um bom jogador não faz jogadas duras. Em vez disso, ele joga de uma maneira que após cada tacada as bolas parem em uma posição em que a próxima tacada é fácil novamente. E um programador não é bom porque pode escrever código complicado - ele é bom porque pode evitar escrever código complicado.

Eu compilar e testar se uma das seguintes condições for atendida:

• A última compilação ocorreu 15 minutos atrás
• A última compilação foi realizada há 25 linhas
• Nova função / sub-rotina foi implementada
• Grande mudança
• Novo recurso (ou um bug disfarçado de recurso)
• Correção de bug (removido um "recurso")
• Estou entediado

A frequência com que executo e teste o código depende do idioma em que estou trabalhando no momento. Se eu estiver codificando um procedimento armazenado, normalmente esperarei até que tudo esteja lá.

Por outro lado, se eu estiver codificando no Lisp, tentarei cada função depois de digitar.

Se eu estiver codificando em Haskell, normalmente faço uma compilação após cada função para capturar qualquer erro de tipo e execute o código depois que tudo estiver pronto.

Eu escrevo apenas o código suficiente para fazer o teste ficar verde. Isso significa que eu executo o teste a cada poucos minutos. Esse é o meu estilo C ++. No entanto, no Ruby eu uso o autoteste, portanto, toda vez que pressiono salvar, recebo feedback dos testes por meio de um pop-up agradável. Eu nem paro de escrever código, isso acontece apenas em segundo plano.

Três vezes por hora, precisando ou não.

Fazemos a programação do primeiro teste e confirmamos apenas o código de trabalho no VCS. O smolderbot vai e verifica o repositório a cada 20 minutos e executa o conjunto de testes. Quaisquer falhas são enviadas imediatamente para toda a equipe de programação para correção imediata.

Para mim, não se trata do quanto eu escrevo. Eu posso escrever milhares de linhas de código simples sem precisar testá-lo. Mas quando estou escrevendo um código mais difícil, tento testar cada função individualmente depois de escrever um conjunto coeso delas.

Às vezes, porém, ver o código em execução é um grande incentivo motivacional, quando você não executa nada há algum tempo, é bom vê-lo funcionando.

Para mim; -
Linha do tempo curta (não há muito tempo para pensar) - escreva código, compile, teste. depurar
Tempo suficiente - enquanto (feito) {write pequeno código, compilação}, testar, depurar

Eu testei para cada conceito de codificação. Às vezes, isso é uma função ou classe e, às vezes, nada mais é que uma declaração if. Uma vez que o conceito funcione, vá para o próximo.

Eu tento escrever testes antes do código. Eu executo meus testes pelo menos duas vezes antes de uma confirmação. Em seguida, ele é executado novamente com o servidor de integração contínua.