Questões de Concurso sobre Test-Driven Development (TDD)

testes comecem por uma operação complexa;

casos de teste menores dispensem a escrita de asserções;

testes de recursos complexos, como acesso a dados, sejam especificados como testes de integração;

coleções de objetos sejam implementadas sem coleções e, após testadas, sejam reescritas para funcionar com coleções;

os desenvolvedores registrem nos comentários da ferramenta de versionamento os testes que foram criados, já que a execução de um teste afeta a execução de outro.

é concentrado na criação de um modelo de domínio que utiliza uma linguagem comum compartilhada entre todas as partes envolvidas no projeto.

coloca ênfase na qualidade do código e na confiabilidade do software, por meio da criação de testes unitários antes de escrever o código de produção.

enfatiza a qualidade da comunicação e a compreensão compartilhada das funcionalidades do software entre as partes interessadas, incluindo desenvolvedores, testadores e partes de negócios.

recomenda criação de especificações de comportamento, usando linguagem natural (Gherkin, por exemplo), a qual descreve o comportamento esperado do software em termos de cenários e casos de uso.

Escrever o código de produção, criar os testes automatizados e depois refatorar o código.

Criar os testes automatizados, escrever o código de produção para passar nos testes e depois refatorar o código.

Refatorar o código existente, escrever novos testes automatizados e depois implementar novas funcionalidades.

Escrever os casos de teste, refatorar o código existente e depois implementar o código de produção.

Implementar o código de produção, refatorar o código, e por último, criar os testes automatizados.

Os testes automatizados não são usados para validar o comportamento do código.

Os testes automatizados são escritos antes da implementação do código funcional.

Os testes automatizados são opcionais e podem ser ignorados.

Os testes automatizados devem ser escritos após a implementação do código, mas antes de sua revisão.

Os testes automatizados são escritos após a implementação do código funcional.

independentes de outros componentes do sistema, permitindo sua execução isolada.

integrados com o sistema de desenvolvimento, automatizando a execução dos testes a cada alteração no código.

projetados para serem reutilizáveis em diferentes contextos, reduzindo o tempo de escrita de testes.

focados na cobertura de código, garantindo que todas as linhas de código sejam testadas.

escritos em linguagem natural, facilitando a compreensão por stakeholders não técnicos.

um processo focado na promoção e venda de produtos existentes para um novo mercado.

uma fase de desenvolvimento de produto onde se definem as características técnicas detalhadas.

uma técnica de marketing para identificar o público-alvo de um novo produto.

um processo iterativo de entendimento das necessidades dos usuários e validação de ideias de produto.

TDD.

Pair Programming.

DbC.

Code Review.

Verificação Formal.

Na fase red, os desenvolvedores escrevem testes de aceitação que devem falhar inicialmente.

Na fase green, os desenvolvedores escrevem o código mínimo necessário para fazer o código passar no teste.

Na fase refactoring, os desenvolvedores buscam otimizar o código de novas funcionalidades reprovadas no teste.

Na fase red, os desenvolvedores revisam o código para identificar oportunidades de melhoria.

Na fase green, os desenvolvedores documentam as mudanças realizadas na fase refactoring.

Continuous Deployment

Pair Programming

Test-Driven Development (TDD)

Feature-Driven Development (FDD)

Escrever código de produção antes de criar testes para garantir que o código funcione conforme o esperado.

Desenvolver um conjunto de testes abrangentes apenas após a conclusão do desenvolvimento do código.

Criar e executar testes automatizados antes de escrever o código de produção para garantir que o código atenda aos requisitos.

Escrever código de produção e testes simultaneamente sem um processo definido para assegurar a funcionalidade.

Utilizar testes manuais para verificar o funcionamento do código antes de publicá-lo.

Certo

Errado

Reduzir a duplicação de código, reorganizando métodos em superclasses e subclasses, mantendo a lógica original e facilitando a manutenção.

Substituir o uso de condicionais complexos por múltiplos métodos, mesmo que isso aumente o número de classes. Como resultado da refatoração, teremos um código de mais difícil entendimento, porém mais fácil de manter.

Eliminar a necessidade de refatoração futura, consolidando toda a lógica da aplicação em um único ponto central.

Garantir que todas as funcionalidades sejam agrupadas em uma única classe principal, eliminando a necessidade de métodos abstratos.

Forçar o desenvolvedor a implementar um padrão de projeto específico desde o início para evitar futuras modificações na estrutura de classes.

revisar código, escrever testes de aceitação e escrever testes unitários.

escrever testes unitários, escrever código de produção e revisar código.

escrever testes de aceitação, escrever código de produção e revisar código

escrever testes unitários, escrever testes de integração e escrever o código de produção.

Escrever todos os testes, implementar todo o código, executar todos os testes e, depois, corrigir o código a partir do relatório de falhas.

Escrever todos os testes, garantir que todos falham, implementar todo o código, executar cada teste um a um e corrigir imediatamente o código até tudo funcionar.

Escrever um teste, executá-lo e vê-lo falhar, implementar o código necessário para passar em todos os testes já criados, refatorar o código e, em seguida, repetir todo o processo.

Escrever todos os testes de unidade, implementar todo o código, executar todos os testes de unidade, corrigir todos os erros encontrados nas unidades, escrever todos os testes de integração, executar todos os testes e corrigir o código a partir do relatório de falhas.

Refatorar o código existente com foco na qualidade, escrever todos os testes para o novo código, testar todo o código e corrigi-lo a partir do relatório de falhas.

a lógica da aplicação deve considerar o modo de persistência de objetos nos repositórios;

as entidades serão definidas pelos atributos que as descrevem;

os analistas de negócio e de requisitos serão os responsáveis pela definição da Linguagem Ubíqua;

os objetos do domínio serão modelados com responsabilidades do próprio armazenamento, mas não da própria exibição;

uma operação deve ser adicionada ao modelo como uma interface autônoma, declarada como um serviço, quando não for uma reponsabilidade natural de uma Entidade ou de um Objeto de Valor.

refactoring.

continuous integration.

test-first.

integração contínua.

small releases.

antes de implementar alguma funcionalidade em si.

durante o período de homologação.

após as funcionalidades serem construídas.

quando a primeira leva de funcionalidades planejadas forem codificadas em algum sprint.

pelos testes de interface automatizado, seguidos pelos testes unitários.

Transaction-driven development, Branch-driven Development e Framework-driven Development.

Test-driven development, Behavior-driven Development e Feature-driven Development.

Transaction-driven development, Behavior-driven Development e Function-driven Development.

Test-driven development, Branch-driven Development e Function-driven Development.

é chamado imediatamente, após o método de teste ter sido executado e o resultado registrado.

é chamado antes da execução dos testes de uma classe específica.

é chamado para preparar a definição de contexto de teste.

executa o teste sem coletar o resultado.

Cobertura de código.

Teste de regressão.

Correção de softwares legados.

Depuração simplificada.

Documentação de sistema.