Capítulo 9 — Programação II
Mapa da aula
Aula 09 publicada. Mapa, exemplo, EX025.
flowchart TD
N0["9.1 Módulos e interfaces"]
N1["9.2 Testes negativos"]
N2["9.3 Dependências"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX025"]
Desenho lógico
flowchart LR
N0["9.1 Módulos e interfaces"]
N1["9.2 Testes negativos"]
N2["9.3 Dependências"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3 --> Q["EX025"]
[9.1 Módulos e interfaces]
|
v
[9.2 Testes negativos]
|
v
[9.3 Dependências]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX025]
Objetivos de aprendizagem
Você vai (1) estruturar programas em módulos com interfaces claras; (2) escrever testes, inclusive testes negativos do comportamento de segurança; (3) gerenciar dependências com segurança.
9.1 Módulos e interfaces
Em Programação II, Sofia constrói um pequeno motor de regras tarifárias como vários módulos: parsing, consulta de tarifas, regras de desconto e saída. Cada módulo expõe uma interface estreita e esconde seus detalhes internos. Daniel explica por que isso importa para a segurança: interfaces estreitas são mais fáceis de revisar, e um módulo que recebe do parser apenas dados validados não precisa repetir todas as verificações. Isso é economia de mecanismo no nível do código. Quando o módulo de descontos mais tarde precisa de uma mudança, Sofia pode revisar só sua interface e seus testes, e não o programa inteiro, o que reduz a chance de introduzir uma falha em outro lugar.
9.2 Testes negativos
Sofia escreve testes unitários para tarifas normais, e então Daniel pede testes negativos: entradas que precisam ser rejeitadas. Um desconto infantil não pode valer para um cartão de adulto; uma zona tarifária fora da rede deve gerar um erro; um valor com mais de duas casas decimais deve ser recusado. Bugs de segurança muitas vezes moram naquilo que um programa aceita por engano, então os testes devem mostrar que entradas ruins falham. Ela roda os testes automaticamente a cada mudança. Os testes negativos também documentam a intenção: um desenvolvedor posterior consegue ver que rejeitar essas entradas foi deliberado, e não um acidente a ser removido.
9.3 Dependências
O programa de Sofia usa um pacote de terceiros para ler arquivos de configuração. Daniel lhe mostra como fixar a versão, registrar de onde ele veio e verificar avisos de segurança publicados. O NIST SP 800-218, o Secure Software Development Framework, recomenda práticas como rastrear os componentes e responder às vulnerabilidades encontradas neles. Uma dependência é código que outra pessoa escreveu e que roda com os privilégios do seu programa. Sofia aprende a preferir a biblioteca padrão quando ela basta, escolher pacotes bem mantidos nos demais casos e avaliar quanto código cada nova dependência traz, já que cada linha faz parte da superfície de ataque do sistema.
Exemplo resolvido
Sofia modulariza um motor de regras tarifárias, acrescenta três testes negativos que precisam falhar com segurança e fixa e registra uma dependência segundo as práticas do SP 800-218.
Caso sintético. O motor e o pacote são sintéticos; o SP 800-218 é real.
Erros e limites
Os testes mostram a presença de verificações, não a ausência de todos os bugs. Dependências fixadas ainda precisam de atualização quando surgem avisos de segurança.
Exercícios
-
EX025 — Benefício da interface estreita. Como interfaces de módulo estreitas ajudam a revisão de segurança? Rubrica: 3 = menos para revisar, e dados validados não precisam ser verificados de novo em toda parte;; 2 = revisão;; 1 = vago;; 0 = nenhuma.
-
EX026 — Exemplo de teste negativo. Dê um teste negativo do motor de Sofia. Rubrica: 3 = desconto infantil em cartão de adulto rejeitado, erro para zona fora da rede ou valor com três casas recusado;; 2 = um;; 1 = teste positivo;; 0 = nenhuma.
-
EX027 — Prática com dependências. O que o SP 800-218 recomenda sobre componentes de terceiros? Rubrica: 3 = rastreá-los e responder às vulnerabilidades encontradas neles;; 2 = rastrear;; 1 = ignorar;; 0 = nenhuma.
Síntese
Desenho modular, testes negativos e dependências gerenciadas tornam os programas mais fáceis de confiar e de manter confiáveis.
Continue estudando — aula 09 (capítulo 09 de 50)
← Capítulo 08 · Índice das aulas · Capítulo 10 →
Continue para a próxima aula já escrita.