Corner Cases Guide

This guide below must be used for each development task, in order to identify possible "corner cases" not yet covered by the unitary and integrated tests crated for the task. This guide should be applied for each method/flow that exists within the code.

Template Guide

  • Se o tamanho for grande

  • Se o tamanho for pequeno

  • Se o fluxo/volume for muito grande

  • Se o fluxo/volume for pequeno

  • Se for zerado

  • Se for número muito grande

  • Se travar

  • Se cair a conexão [antes, durante, depois, sem commitar]

  • Se a conexão não fechar

  • Se acumular conexões

  • Se corromper

  • Se reiniciar / cair

  • Se perder as informações

  • Se ficar lento

  • Se demorar

  • Se for muito rápido

  • Se mudar a ordem das coisas

  • Se for acessado/utilizado/executado paralelamente (multiplas threads)

    • Tem lock? Precisa ter lock?

  • Se já estiver na memória

  • Se não estiver na memória

Examples

Componente: OptimizationQueue

  • Se o fluxo for muito grande

    • Se o fluxo for realmente muito grande, a thread que estiver executando a fila vai apenas demorar para executar. Se houver alguma thread esperando essa execução isso pode causar um overhead. O consumo de memória também aumentaria, considerando que a lista de inverted indices para otimizar é armazenada em memória

  • Se travar

    • A estrutura da fila fica em memória. Se travar, a lista de arquivos para otimizar vai ficar indisponível até o servidor ser reiniciado

  • Se cair a conexão

    • Não é um problema.

  • Se corromper

    • Esta classe recebe apenas referências e as armazena em uma lista. O máximo que pode acontecer é não ser possível navegar no mapa contendo os inverted indices caso eles estejam corrompidos. Esta classe não sobrescreve dados, portanto não tem como corromper arquivos

  • Se o fluxo for bem pequeno

    • Não é um problema.

  • Se reiniciar

    • A lista é reiniciada na primeira vez que alguém solicita uma instância da classe. Por ser uma estrutura em memória apenas não há problema em reiniciar

  • Se perder as informações

    • A lista pode ser recriada a qualquer momento

  • Se ficar lento

    • Se não houver a garantia de que os arquivos serão processados mais rapidamente do que são criados, poderia acontecer um loop infinito. Altamente improvável, mas não impossível.O OptimizationQueue não terá problemas nesse cenário. O único efeito da lentidão sobre o OptimizationQueue é que a inicialização da instância vai demorar mais

  • Se a ordem inverter

    • Não há problema em inverter a ordem dos arquivos, eles apenas seriam processados em ordem diferente

  • Se for zerado

    • A lista é recriada dinamicamente conforme os InvertedIndices são modificados e é possível solicitar a recriação da lista a qualquer momento.