O que um decorador realmente faz com sua função Você quer medir o tempo de cada função que chama uma API externa lenta. Pode colar chamadas a time.perf_counter() em cada uma, ou escrever a medição uma única vez e aplicá-la em todas. Um decorador é a segunda opção: é uma função que recebe outra função, a envolve em um comportamento extra e devolve a versão envolvida com o mesmo nome original. ...
Execute 0.1 + 0.2 em um shell Python e você não recebe 0.3. Recebe 0.30000000000000004. Tente em JavaScript, Java, Go, C ou Rust e aparece a mesma cauda de dezesseis dígitos. Cada uma dessas linguagens faz exatamente o que o padrão de hardware determina. Um número que precisaria de infinitos dígitos binários é comprimido em 64 bits, e algo precisa ser descartado. Por que 0.1 não pode ser guardado de forma exata em binário Computadores guardam números de ponto flutuante na base 2. Na base 2, a fração 1/10 tem uma expansão periódica, do mesmo jeito que 1/3 se repete para sempre na base 10 (0.3333...). Escrito por completo, 0.1 em binário começa assim: ...
Uma busca em um dicionário Python leva cerca de 100 nanossegundos, não importa se o dicionário tem 1.000 ou 1.000.000 de chaves. Um laço duplo que procura duplicatas em uma lista leva meio milissegundo com 200 itens e 136 milissegundos com 3.200. Dezesseis vezes a entrada, quase 280 vezes a espera. Mesma máquina, mesmo Python. A notação Big O é o nome dessa diferença. O que a notação Big O mede Big O descreve como o tempo de execução (ou o uso de memória) de um trecho de código cresce conforme a entrada aumenta. Não é uma leitura de cronômetro, e não importa se o seu notebook é rápido ou lento. O que importa é a forma da curva de crescimento: ao dobrar a entrada, o tempo dobra, quadruplica ou quase não muda? ...
Rode git reset --hard num commit que seu time já deu pull nele, e seu histórico passa a discordar do deles. Rode git revert num typo que você nem chegou a dar push nele, e acaba de acrescentar um commit inútil ao log. O Git tem quatro comandos para desfazer mudanças, restore, reset, commit --amend e revert, e eles não são intercambiáveis. Escolher o errado ou não faz nada, ou faz muito mais do que você queria. ...
Aqui está uma classe que você não consegue testar com um teste unitário sem um banco de dados ativo e um servidor SMTP funcionando: 1 2 3 4 5 6 7 8 9 10 11 public class OrderService { private readonly SqlOrderRepository _repository = new SqlOrderRepository("Server=prod-db;Database=Orders;..."); private readonly SmtpEmailSender _emailSender = new SmtpEmailSender("smtp.company.com"); public void PlaceOrder(Order order) { _repository.Save(order); _emailSender.Send(order.CustomerEmail, "Order confirmed"); } } OrderService cria o próprio SqlOrderRepository e SmtpEmailSender com new, connection string e tudo mais. Todo teste que toca PlaceOrder precisa de um banco de dados Orders real e um servidor de e-mail real, ou falha antes mesmo da sua assertion rodar. A lógica que você quer testar tem duas linhas: salvar o pedido, enviar a confirmação. Ela está soldada a duas classes concretas que você não consegue trocar. ...
Uma função pode ter 100% de cobertura de testes unitários e a página que a chama ainda assim pode retornar um 500 em produção. Isso não é uma contradição. Testes unitários, de integração e end-to-end verificam coisas diferentes, e uma suíte forte em um e fraca em outro tem um buraco específico e previsível. O que cada tipo de teste verifica: unitário, integração e end-to-end Pegue uma funcionalidade de cadastro: uma função valida a entrada, grava uma linha em um banco de dados e envia um email de boas-vindas. Três testes podem cobrir isso, e cada um responde a uma pergunta diferente. ...
Execute isto no Node ou no console do navegador: 1 2 3 4 console.log("1"); setTimeout(() => console.log("2"), 0); Promise.resolve().then(() => console.log("3")); console.log("4"); O resultado é 1 4 3 2. Um setTimeout com um delay de 0ms ainda é executado depois do callback da promise, e os dois esperam que todas as linhas de código síncrono abaixo deles terminem primeiro. O async/await é construído sobre essa ordem, não é algo novo. A maior parte do comportamento surpreendente do JavaScript assíncrono vem de tratar o await como se ele pausasse o programa inteiro, quando na verdade ele só pausa a função em que está. ...
Seu frontend roda em http://localhost:5173, sua API em http://localhost:4000, e a chamada fetch que funcionava sem problemas no Postman falha no navegador com uma parede de texto vermelho: Access to fetch at 'http://localhost:4000/api/users' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Seu servidor pode muito bem ter processado a requisição e retornado um 200. O navegador simplesmente se recusou a entregar a resposta ao seu JavaScript. ...
Depurando um bug que só acontece em uma máquina sem Visual Studio Um bug reproduz no servidor de teste e não no seu notebook. O servidor de teste não tem Visual Studio, e instalar uma IDE inteira ali só para colocar um breakpoint não é uma opção. A depuração remota existe para esse caso. Um programa pequeno e independente roda na máquina alvo, seu Visual Studio local se conecta a ele pela rede, e você ganha breakpoints e inspeção de variáveis em um processo que não está rodando nem perto da sua mesa. ...