Resumo20050123

De Stoq Wiki
Ir para: navegação, pesquisa

Continuação da reunião do dia 20/01/2006. Os principais assuntos da reunião foram:


Esta reunião realizada no dia 24/01/2006, com os resultados da pesquisa feita por Rudá Filgueiras e Grazieno Pellegrino, para melhor adaptar a suíte de testes à realidade do desenvolvimento da plataforma stoq.

Continuacao dos 10 Princípios: <verbatim> Jan 24 11:07:37 ruda_porto Nos tinhamos paradas parado no item 5) Jan 24 11:09:02 ruda_porto 6) Os testes devem examinar o codigo para ter certeza que ele faz o que deve fazer é apenas metade do trabalho, a outra metade é garantir que ele não faz nada mais do que isso. Jan 24 11:09:49 ruda_porto - Ou seja, examinar de que forma o software impede e garante a integridade contra usos inesperados Jan 24 11:10:17 ruda_porto A próxima é muito importante: Jan 24 11:11:04 ruda_porto 7) Evitar teste cases descartáveis, a não ser que o programa seja realmente um programa descartável. Jan 24 11:11:47 ruda_porto - A questão aqui é ter como reexecutar os testes sempre que necessário Jan 24 11:12:36 ruda_porto 8) Não planeje um esforço de teste sobre a idéia pré-concebida de que nenhum erro será encontrado. Jan 24 11:13:08 ruda_porto - Esse item também já foi discutido. O bom teste é aquele que encontra mais errors. Jan 24 11:13:55 ruda_porto 9) A probabilidade da existência de mais erros em uma parte de um programa é proporcional ao números de erros já encontrados nessa mesma parte. Jan 24 11:15:03 ruda_porto - Essa afirmação é importante na medida que as áreas com mais bugs encontrados até hoje, devem ser melhor testadas. Jan 24 11:15:52 ruda_porto 10) Escrever testes de software é uma tarefa extremamente criativa e intelectualmente desafiante. Jan 24 11:16:27 ruda_porto - A criatividade necessária para testar excede a criatividade usada para criar. Jan 24 11:17:53 beyond ok, não tenho comentários. Acho que agora é terminar de documentar isso no nosso wiki e tomarmos esse conhecimento como fonte de referencia para novos testes </verbatim>

Conceitos sobre WhiteBox e BlackBox: <verbatim> Jan 24 11:17:36 ruda_porto Só falta definir os conceitos de balck-box e white-box teste. Jan 24 11:18:51 ruda_porto Black-box: é o teste que explora o código com dados de entrada e compara a saída experada de acordo com os requisitos Jan 24 11:19:39 ruda_porto - não é necessário e até desejável ver o código, pois os detalhes de implementação são irrelevantes. Jan 24 11:20:25 ruda_porto - porém necessita de documentação prévia dos requisitos que o sistema foi projetado para cumprir Jan 24 11:20:54 ruda_porto - trata as partes do código como caixas-pretas. Jan 24 11:21:37 ruda_porto White-box: é o teste que analisa e verifica a implementação interna do código Jan 24 11:22:09 ruda_porto - é necessário estudar o código Jan 24 11:22:24 ruda_porto - apenas garante que o algoritimo funciona Jan 24 11:23:20 ruda_porto - não tem como garantir que os requisitos são atendidos Jan 24 11:23:56 ruda_porto beyond, para mim aqui está o ponto importante: qe tipo de teste é o mais desejável e efetivo para o que precisamos? Jan 24 11:24:25 ruda_porto Em geral se foca mais no black-box e depois se complementa com alguns teste white-box </verbatim>

Discussões acerca de qual método usar: <verbatim> Jan 24 11:37:41 beyond ruda_porto, acho que o ideal seria mesmos usarmos um pouco dos dois tipos Jan 24 11:39:22 beyond de certa forma acho que podemos comparar um pouco os nossos doctests com o blackbox Jan 24 11:39:30 beyond e os testes da pylib com white-box Jan 24 11:39:38 beyond ou estou enganado ? Jan 24 11:41:40 ruda_porto beyond, o fato de ser um ou outro é o foco. Jan 24 11:42:10 ruda_porto beyond, o doctestes é interessante para documentar, seja os requisitos, seja os detalhes de implementação Jan 24 11:43:13 ruda_porto beyond, enquanto as unidades de teste com py.lib, tentam automatizar mais o processo, de forma mais concisa. Jan 24 11:43:37 ruda_porto Mas ambos podem ser white ou balck box de acordo com o foco. Jan 24 11:44:46 beyond poderiamos pegar modulos de dominio que faltam ser testados e nos focarmos num desses tipos especificos de testes Jan 24 11:45:10 beyond de forma a podermos avalia-los de um modo mais preciso Jan 24 11:46:19 beyond white-box poderia ser perfeitamente aplicado no módulo domain.payment.methods que possui métodos complexos e é um local de fácil surgimento de bugs Jan 24 11:47:27 beyond black-box poderia ser aplicado no wizard de vendas, onde iriamos verificar as entradas de dados e depois fazer checkagens na base de dados verificando os resultados obtidos pelo wizard Jan 24 11:48:09 beyond nesse caso poderiamos usar kiwi-ui-tests e fazer essas verificações em alguns hooks que o jdahlin está adicionando lá Jan 24 11:52:14 ruda_porto beyond, acho que a idéia é essa mesmo, fazer exemplos de cada um para entender melhor Jan 24 11:54:17 ruda_porto beyond, o black box é um teste de stresse de entrada e saída de dados com a validação. E isso é perfeitamente aplicável para as classes de domínio, criando instancias, fazendo relacionamentos e comparando com o esperado. Jan 24 11:55:08 ruda_porto beyond, e para isso é preciso ter em mente que ao criar a classe xxx ela é um item de caixa, e ter bem claro qual a saída correta para consistir esses dados de entrada. Jan 24 11:55:09 beyond saída de dados com validação em geral é feita pela parte gui do sistema Jan 24 11:55:23 ruda_porto beyond, não bem isso Jan 24 11:55:51 ruda_porto O que eu digo é mais conceitual de como funciona um processo, por exemplo de fechamento de caixa. Jan 24 11:56:17 beyond ruda_porto, e qual é o seu conceito de fechamento de caixa ? Jan 24 11:56:31 ruda_porto beyond, O problema é justamente essse====

==

Jan 24 11:57:09 ruda_porto beyond, Ter o conceito definido de como esse fechamento ou abertura ou o que quer que seja deve funcionar, conceitualmente, independente da implementação====

==

Jan 24 11:58:17 ruda_porto beyond, Esses testes só dependem da implementação no que diz respeito a API, para executar as operações, mas se a API for a mesma e mudar a implementação, porém ela é conceitualmente equivalente, os testes seriam os mesmos. Jan 24 11:58:48 ruda_porto beyond, no white-box o que importa é exatamente o contrário, testar os detalhes de implementação. Jan 24 11:59:47 ruda_porto beyond, Eu considero o black-box mais importante em geral, e para algoritimos criticos e sucetíveis a erro, seriam escritos testes white-box </verbatim>


Em quais partes do sistema usar WhiteBox e BlackBox? <verbatim> Jan 24 12:00:03 beyond humm, ok. Precisamos entao definir quais parte do sistema necessitam de uma definição precisa de processo e quais necessitam apenas de testes de implementacao Jan 24 12:01:00 beyond para a parte gui do sistema vejo tambem o black-box bastante útil Jan 24 12:01:08 ruda_porto beyond, acho que isso é o mapa da mina==== Ele vai nos dar a visão completa do sistema.

==

Jan 24 12:01:18 beyond quando a dominio já teriamos uma mistura entre as duas taticas Jan 24 12:01:55 ruda_porto beyond, sim, concordo, na parte gui o black-box, pois o white box da gui são os testes do próprio kiwi ou pygtk Jan 24 12:02:02 beyond que tal essa combinação ? white-box para modulos de dominio de pagamento e black-box para wizard de venda ? Jan 24 12:02:35 beyond para o wizard de vendas voces dependeriam de algumas mudanças em kiwi-tests que o jdahlin está fazendo no momento Jan 24 12:02:41 ruda_porto beyond, mas qual código de domínio quer testar com white-box? Jan 24 12:02:46 beyond creio que essa semana ele termine Jan 24 12:03:05 beyond domain.payment.methods Jan 24 12:04:13 beyond vamos começar. É abrir bugs, adicionar comentários e mandar bala. Com certeza surgirao duvidas quanto ao processo do wizard de vendas e tambem quanto ao funcionamento do domain.payment.methods Jan 24 12:04:32 beyond basta voces sairem a procura dessa informacao e a documentarem Jan 24 12:04:59 ruda_porto beyond, ok Jan 24 12:06:02 ruda_porto mas de qualquer forma, que gostaria de terminar o domain/person como exercício de white e black box no mesmo módulo, o que acha? </verbatim>

Avisos importantes: <verbatim> Jan 24 13:46:36 beyond ruda_porto, grazieno, o jdahlin acaba de fazer um commit que adiciona um hook que é chamado logo apos os testes do kiwi Jan 24 13:46:46 beyond revisao 2186 Jan 24 13:47:27 IWYGD beyond: new order > add product > add delivery > select an item > click edit (bug) Jan 24 13:47:41 beyond ruda_porto, grazieno , stoq/tests/gui/salewizard.py esse arquivo demonstra o uso do hook Jan 24 13:47:45 beyond é bastante interessante Jan 24 13:47:59 beyond IWYGD, vou olhar </verbatim>