Conversation
| type dbInterface interface { | ||
| GetPipelinesByDay(day int) ([]storage.Pipeline, error) | ||
| InsertExecution(e storage.Execution) error | ||
| GetLastExecutionsForAllPipelines() ([]storage.Execution, error) |
There was a problem hiding this comment.
Você provavelmente vai precisar passar algum tipo de quantidade aqui, não?
Outra coisa importante, a interface pode ser um bom lugar para documentar bem essas funções. Por exemplo, o método GetPipelinesByDay(int) retorna todos os pipelines do dia especificado, sempre no mês corrente.
| log.Fatal("error trying get environment variable: $MONGODB is empty") | ||
| } | ||
|
|
||
| errorLimitStr := os.Getenv("ERROR_LIMIT") |
There was a problem hiding this comment.
ERROR_LIMIT é a quantidade de vezes que a execução de um determinado mês pode falhar? Se sim, poderia chamar ela RETRY_LIMIT, por favor? Essa é a forma que ela se apresenta em outros programas.
Também poderia comentar essa variável? Vale super pena documentar esse parâmetro do programa.
| } | ||
|
|
||
| errorLimitStr := os.Getenv("ERROR_LIMIT") | ||
| if uri == "" { |
There was a problem hiding this comment.
| if uri == "" { | |
| if errorLimitStr == "" { |
| } | ||
|
|
||
| errorLimitStr := os.Getenv("ERROR_LIMIT") | ||
| if uri == "" { |
There was a problem hiding this comment.
Lembrando que o strconv.Atoi falha quando a variável é vazia. Mas entendo que você quis dar uma mensagem mais bacana quando o erro mais recorrente.
| } | ||
|
|
||
| func getPipelinesToExecuteToday(db *storage.DBClient) ([]storage.Pipeline, error) { | ||
| func getPipelinesToExecuteToday(db dbInterface) ([]storage.Pipeline, error) { |
There was a problem hiding this comment.
Eu acho arretada essa forma que programas em Go crescem em complexidade. Hoje em dia me soa bastante orgânico, natural? Nenhuma modição em extends ou implements! Note que você não precisou modificar em nada storage.DBClient!
| }, | ||
| } | ||
|
|
||
| type fakeFinder struct { |
| "github.com/matryer/is" | ||
| ) | ||
|
|
||
| var pipelinesDB = []storage.Pipeline{ |
There was a problem hiding this comment.
Tu deve precisar criar vários desses a medida que o teste aumenta.
Sugestão: cria os storage.Pipeline baseado nas características que você quer, coloca nomes sugestivos neles (dada as características de erro ou algo simples ou complexo ou algo assim) e coloca eles na parte de baixo do programa.
Daí, cria o []storage.Pipeline dentro de cada método. A pessoa lendo esse arquivo ver os casos de teste e quando for ler um terminado método vai entender mais fácilmente o caso sendo testado.
| // 2º descartar se o número de execuções com erro for igual ou maior que o limite | ||
| // ... | ||
| // por último aplicar filtro de tamanho | ||
| func TestPrioritizeAndLimit_LimitTest(t *testing.T) { |
2 participants
Para poder pensar nas 2 funções getPipelinesThatFailed e getPipelinesForCompleteHistory precisei pensar no processo como um todo a fim de deixar essas funções "mais simples", e então centralizar as regras que queremos aplicar no prioritizeAndLimit. Por isso fiz essa primeira versão de teste, o que me ajudou a pensar nas funções novas no storage também =].
O próximo passo é implementar as funções no storage para depois fazer o getPipelinesThatFailed.
E acredito que esse processo deve gerar algum ajuste nas ideias descritas aqui para a priorização.