Mudanças entre as edições de "Discussão:Projeto/Ourolux/Documentação/NormalizarPedido"
(→Solução vs implementação: nova seção) |
(→Cenário confuso: nova seção) |
||
| Linha 18: | Linha 18: | ||
É sempre bom definir de modo separado a solução da implementação. Por exemplo, [[Validade de sincronismo de acordo com fuso horário do vendedor]] trata essa separação, onde a [[Validade de sincronismo de acordo com fuso horário do vendedor#Solução declarativa|solução]] dita as regras que devem ser seguidas na criação da implementação, enquanto que a [[Validade de sincronismo de acordo com fuso horário do vendedor#Pré-detalhes da informação imperativa|implementação]] trata de detalhes de como essas regras serão tratadas em um nível mais baixo, desde distribuição dos dados, explicação da estrutura das tabelas até mudanças necessárias em consultas no sistema. | É sempre bom definir de modo separado a solução da implementação. Por exemplo, [[Validade de sincronismo de acordo com fuso horário do vendedor]] trata essa separação, onde a [[Validade de sincronismo de acordo com fuso horário do vendedor#Solução declarativa|solução]] dita as regras que devem ser seguidas na criação da implementação, enquanto que a [[Validade de sincronismo de acordo com fuso horário do vendedor#Pré-detalhes da informação imperativa|implementação]] trata de detalhes de como essas regras serão tratadas em um nível mais baixo, desde distribuição dos dados, explicação da estrutura das tabelas até mudanças necessárias em consultas no sistema. | ||
| + | |||
| + | == Cenário confuso == | ||
| + | |||
| + | Cara, esses cenários estão pessimamente testáveis... Assim, eles não ajudam na capacidade de escrita do teste. | ||
| + | |||
| + | Para ser facilmente testável, é melhor separar o cenário em Dados, Operação e Assertiva, como nos exemplos: | ||
| + | * [[Inserção Motivo de Cadastro de Pedidos#Cenários]] | ||
| + | * [[Bonificação com Saldo Fixo#Cenários]] | ||
| + | * [[Desconto negociado#Cenários]] | ||
| + | * [[Observação de Nota Fiscal#Cenários]] | ||
| + | * [[Funcionalidade/Limite de crédito#Cenários de fluxo]] | ||
Edição das 11h26min de 7 de dezembro de 2016
Definição do que é normalizado
Na necessidade da normalização tem isso:
Se o pedido a ser copiado tiver alguma pendência [...], este pedido precisa ser normalizado para que possa ser criado no GeoSales. <sic>
Foi bem cíclica a definição. Eu esperava alguma coisa mais ou menos com esse sentido:
Se o pedido a ser copiado tiver alguma pendência [...], essas pendências de criação são tratadas de modo que o um novo pedido surja no GeoSales. Esse novo pedido é o que é chamado de pedido normalizado.
Autor?
Caras, se liguem, façam login!
É de graça e fácil
Solução vs implementação
É sempre bom definir de modo separado a solução da implementação. Por exemplo, Validade de sincronismo de acordo com fuso horário do vendedor trata essa separação, onde a solução dita as regras que devem ser seguidas na criação da implementação, enquanto que a implementação trata de detalhes de como essas regras serão tratadas em um nível mais baixo, desde distribuição dos dados, explicação da estrutura das tabelas até mudanças necessárias em consultas no sistema.
Cenário confuso
Cara, esses cenários estão pessimamente testáveis... Assim, eles não ajudam na capacidade de escrita do teste.
Para ser facilmente testável, é melhor separar o cenário em Dados, Operação e Assertiva, como nos exemplos: