--- marp: true theme: apostila paginate: true title: "Como criar, testar e corrigir um projeto interativo?" description: "Apresentação didática do capítulo 10: Como criar, testar e corrigir um projeto interativo?" workbook: "pensamento-computacional-6-ano" chapter: 10 order: 10 tone: "violet" image: "/images/exploring/debugging-loop.png" footer: "Pensamento Computacional · 6º Ano" --- # Como criar, testar e corrigir um projeto interativo? ## Capítulo 10 --- # Ao final, você entenderá melhor… - Repetição - condição simples - bug - depuração - teste - melhoria - mini jogo ou animação interativa - situações extremas, condições de conclusão e registro do projeto --- # Uma situação para observar Um jogo de tabuleiro só fica divertido quando as regras funcionam. Se uma regra permite jogar para sempre sem chegar ao final, o grupo testa, conversa e ajusta. Projetos digitais também melhoram por versões. Neste capítulo, juntaremos sequência, repetição e condição simples para criar interação. Depois, vamos testar como investigadores: observar o que aconteceu, localizar o bug, corrigir uma parte e testar novamente. --- # Antes de seguir, pense nisso > **Ponto de partida:** Projetos interativos não ficam prontos apenas porque funcionaram uma vez. Precisamos definir o que significa “funcionar”, experimentar entradas comuns e incomuns e registrar as decisões para que outra pessoa consiga compreender a lógica. --- ![bg contain Ciclo de teste, observação, hipótese, correção e novo teste](/images/exploring/debugging-loop.png) --- # Observe e teste a explicação Um teste é mais útil quando possui uma entrada conhecida e um resultado esperado. A diferença entre o esperado e o observado oferece uma pista sobre o bug. Se várias coisas forem alteradas ao mesmo tempo, fica difícil descobrir qual mudança resolveu — ou criou — o problema. Na depuração, formulamos uma hipótese, fazemos a menor alteração possível e testamos novamente. Depois da correção, repetimos testes que já funcionavam. Esse processo, chamado de **teste de regressão**, verifica se a solução de um erro não danificou outra parte do projeto. --- # Organize o caminho 1. Descreva o resultado esperado e o resultado observado. 2. Encontre o menor caso que ainda apresenta o erro. 3. Altere uma causa provável por vez. 4. Teste a correção e confirme que o restante continua funcionando. --- # Conecte as descobertas Além do caminho esperado, teste situações próximas dos extremos permitidos, chamadas de **casos-limite**: valores muito pequenos ou grandes, teclas pressionadas rapidamente, personagem na borda e ações fora de ordem. Também teste entradas inválidas. O projeto deve ignorá-las, apresentar orientação ou responder de modo seguro. Antes de acrescentar efeitos, estabeleça *critérios de conclusão*, como iniciar corretamente, responder às entradas, terminar a rodada e permitir nova tentativa sem reiniciar tudo. --- # A mesma ideia em outros contextos Atletas repetem movimentos para aperfeiçoá-los e usam condições para decidir uma jogada. Músicos repetem trechos e corrigem notas específicas. Em experimentos, cientistas alteram uma variável por vez para entender o efeito. --- # Ideias em construção - **Repetição** Quando uma ação precisa ocorrer várias vezes, um bloco de repetição evita copiar o mesmo comando. Ele representa um padrão de execução. - **Condição simples** Uma condição pergunta se algo é verdadeiro antes de agir: “se tocar na borda, volte” ou “se pressionar espaço, pule”. - **Bug e depuração** Bug é um erro que faz o projeto se comportar de modo diferente do esperado. Depurar é observar, criar uma hipótese, alterar e testar. --- # Ideias em construção · continuação - **Teste e melhoria** Um bom teste tem objetivo: verificar uma regra, uma entrada ou uma saída. Melhorar não é apenas acrescentar efeitos; é tornar o projeto mais claro, estável e divertido. - **Casos-limite e documentação** Caso-limite é uma situação próxima dos extremos permitidos pela regra. Ele revela problemas que o uso comum pode esconder. **Documentar** significa registrar objetivo, controles, regras, testes e decisões importantes. Uma documentação curta ajuda colegas a usar o projeto, reproduzir bugs e continuar a melhoria sem depender apenas da memória de quem programou. --- # Uma história que amplia a ideia Nos primeiros computadores, programas eram preparados com cabos, chaves ou cartões e podiam exigir muito tempo para serem alterados. Na década de 1950, **Grace Hopper** trabalhou em sistemas que traduziam instruções mais próximas da linguagem humana para comandos de máquina. Esses tradutores receberam o nome de compiladores. O compilador A-0, associado ao trabalho de Hopper, foi um passo importante nessa direção. Mais tarde, ela participou da criação de ideias que influenciaram a linguagem COBOL, usada principalmente em sistemas de negócios. Tornar programas mais legíveis também facilitava revisar, testar e corrigir. Ainda hoje, ferramentas modernas indicam erros, executam testes automáticos e registram versões, mas continuam dependendo de uma prática essencial: *comparar o resultado esperado com o observado* e documentar a mudança. --- # Leve esta ideia com você > Mude uma coisa por vez. Se você alterar cinco blocos juntos e o projeto funcionar, não saberá qual mudança resolveu o problema. Testes pequenos produzem pistas melhores. --- # Agora explique com suas palavras 1. Quando é útil usar repetição? 2. Um personagem repete o mesmo passo dez vezes. Qual estrutura pode reduzir a quantidade de blocos? > Responda em voz alta, escute outra explicação e complete sua ideia com um exemplo.