Semana 19 de 2024

Educação

Palestra “Design is testability”, por Titus Winter. Evento promovido pela ACM. Por alguns anos pesquisei com alguma intensidade sobre TDD e, particularmente, sempre considerei essencial em pensar sobre o que testar antes de definir o caso de teste e, posteriormente, o código. Mesmo ao avaliar um código sem caso de testes inicialmente definidos, conceitualmente sempre busco achar um propósito válido para criar o caso de teste dentro do contexto em que foi feito o código a ser testado. Por exemplo, para código produzido por estudantes em disciplinas introdutórias de programação, além de considerar a correção quanto aos requisitos, também penso quanto às construções de código normalmente utilizadas. Ainda quanto aos requisitos, definir um contrato claro e, eventualmente, fornecer a assinatura da função, é algo que busco observar no início da disciplina e, mais para o final, observar se o estudante consegue definir uma função (e seu contrato) de forma clara, inclusive com casos de teste.
- O ponto central da palestra é uma estratégia para projetar e testar o software, com a seleção de técnicas de teste conforme o controle disponível de design. As variáveis são a existência de atributos de qualidade, de controle intectual da entrada e controle intectual da saída. Se existir controle intelectual da entrada e do contrato, usar testes de unidade. Caso não tenhamos ambos, usar property-based testing ou fuzzying.
- Enfim, alguns pontos que destaquei da palestra:
  - “For any possible input value (precondition), we should define an answer (postcondition).” Aqui cabe destacar um ponto, de que em muitos casos temos uma entrada válida, mas não temos uma resposta (ou pós-condição) estabelecida. Na palestra foi mencionado o caso da Linguagem C++ e seus diversos casos de compartamento indefinido (UB - Undefined Behavior).
  - Design By Contract (DBC) vs Test First (TF)/Test Driven Development (TDD). Não seria uma questão de versus, mas de fazer antes do DBC e depois o TF/TDD, ou seja, combiná-los (e nessa ordem). Concordo integralmente.
  - Olhar sobre a possibilidade de usar fuzzy testing guiado por cobertura e análise dinâmica (sem controle intectual da entrada e do contrato).
  - Olhar sobre teste baseado em propriedade (Property-based testing), no caso de sem controle intectual da entrada e do contrato, mas ao menos com boas propriedades definidas.
  - Testability is correlated to good design.
  - Quanto à IA generativa de código de programas, “we should provide the contract, ask for test cases for that contract, and once we are satisfied with those test cases, ask for code that satisfies the contract and test cases.”
  - Strong typing is a good way to introduce good quality design.
  - Quanto à teste de mutação, além de usar a técnica para avaliar a qualidade do conjunto de teste, usá-la para selecionar os casos de teste mais eficazes, ou seja, que matam mais mutantes (no caso, configurando o test driver para executar todos os casos de teste com relação aos mutantes obtidos com todos os operadores de mutação).
Palestra sobre “Alternative grading” por Kevin Lin, da University of Washington (UW). Food for thought sobre repensar a forma de avaliar (e dar nota) em nossos cursos. Algumas coisas já fazemos, como resubmissão, mas melhorar o feedback parece-me essencial (e fazê-lo de forma escalável). Tirar a ênfase das notas (em pontos) e migrar para satisfação de objetivos de aprendizagem, com objetivos organizados em conjuntos mais abstratos. A se pensar.