Testes unitários verificam detalhes internos de implementação dos componentes do sistema, enquanto testes de integração realizam a validação do comportamento do sistema como um todo, permitindo que a refatoração prossiga sem riscos.

Testes unitários validam comportamentos locais e testes de integração validam as interações entre componentes, criando camadas de verificação para garantir que mudanças estruturais não alterem o comportamento observável do sistema.

Testes de integração garantem a correção arquitetural, tornando redundante a realização de testes unitários durante a refatoração, desde que os workflows possam ser validados fim-a-fim.

Testes unitários protegem contra mudanças de interface, enquanto testes de integração garantem estabilidade de desempenho, o que remove a necessidade de refazer os testes após uma refatoração.

Definir uma única tabela para a hierarquia, a qual é compartilhada pela superclasse e todas as suas subclasses, com uma coluna indicando a classe de cada objeto.

Definir uma tabela para a superclasse e uma tabela para as subclasses, contendo uma coluna que aponta para a tabela da superclasse e colunas para os atributos adicionais. 

Definir uma tabela com os atributos da superclasse e uma tabela para cada subclasse contendo os atributos adicionais e a chave primária da superclasse.

Definir uma tabela para cada subclasse, contendo as características definidas na superclasse, assim como as características adicionadas pela subclasse.

O branch new-feature é inicializado em um novo repositório, para o qual o conteúdo do repositório original é copiado e ao qual é adicionada a nova versão do arquivo oldfile.c, bem como o arquivo newfile.c. 

O branch new-feature é selecionado e preparado para commit, o qual ocorre subsequentemente, criando uma nova versão, que contém o arquivo oldfile.c modificado, assim como o novo arquivo newfile.c.

O branch new-feature é criado no mesmo repositório e definido com espaço de trabalho, o qual contém a nova versão do arquivo oldfile.c, mas não o arquivo newfile.c.

O branch new-feature é criado no mesmo repositório e nele é criada uma nova versão, a qual contém o arquivo modificado oldfile.c, assim como o novo arquivo newfile.c. 

CI encorajar o uso de repositórios distintos para evitar interferência entre as diferentes tarefas de desenvolvimento em um projeto, com integração frequente dos repositórios e uso de testagem automática para garantir a ausência de erros, enquanto CD requer o empacotamento e deployment automáticos para reduzir o impacto de mudanças. 

CI envolver o uso de um repositório compartilhado, com automação de build e testagem a cada commit, enquanto CD envolve o empacotamento automático de cada build bem-sucedida, gerando uma nova release e deixando-a pronta para implantação (deployment) nos diferentes ambientes de produção.

CI requerer a realização contínua e automática de testes de integração para garantir que mudanças no código-fonte realizadas nos diferentes ramos (branches) do repositório não comprometam o comportamento correto dos componentes do sistema, enquanto CD envolve a implantação em ambiente de produção para a realização de testes em ambiente real.

CI determinar o emprego de testes unitários automáticos, eliminando a necessidade de testes manuais e garantindo que o comportamento do sistema permaneça correto após cada mudança, enquanto CD implica a realização automática de testes de integração após cada build e o subsequente empacotamento para deployment.

Permitir o uso de sistemas externos reais, como bancos de dados e serviços Web, em testes unitários, o que também permite reproduzir ambientes de execução realistas e melhorar a cobertura dos testes. 

Gerar dados de teste aleatorizados em cada execução, de modo a aumentar a variabilidade dos dados de entrada e, dessa forma, melhorar a confiabilidade, cobertura e robustez dos testes unitários.

Utilizar extensivamente a espera temporizada, como em Thread.sleep(), em testes concorrentes, de modo a estabilizar falhas relacionadas com temporização e reduzir a incidência de comportamentos intermitentes.

Lançar mão de implementações simuladas (mockups) em lugar do acesso ao relógio local e a serviços externos, isolando a unidade em teste e garantindo que cada teste seja independente de efeitos externos.