O produto workflow.validation foi utilizado em um problema real para validar uma demanda de um cliente da empresa HaDi.Com - Solu¸c˜oes para Educa¸c˜ao Ltda. O principal requisito ´e o desenvolvimento de um produto Plone para a inscri¸c˜ao de estudantes no Centro de Educa¸c˜ao Tecnol´ogica e de Pesquisa em Sa´ude. O produto a ser desenvolvido possu´ıa um requisito funcional, cujo objetivo era impossibilitar ao estudante a edi¸c˜ao do seu cadastro ap´os a submiss˜ao do mesmo. Para atender esse requisito foi necess´ario o desenvolvimento de um workflow.
A etapa de cria¸c˜ao do workflow iniciou-se com o cadastramento dos requisitos no produto workflow.validation pelo analista (4.12). Com os requisitos devidamente cadastrados, o desenvolvedor inicia a etapa de codifica¸c˜ao do novo workflow.
Figura 4.12: Requisito cadastrado no produto “workflow.validation”
Ap´os a conclus˜ao da etapa de codifica¸c˜ao, o analista pode validar a codifica¸c˜ao do workflow. Para isso o analista efetua os procedimentos descritos no caso de uso Exporta¸c˜ao do arquivo ZIP (Tabela 4.6) e Executar Teste (Tabela 4.7).
O Trecho de C´odigo 4.7 apresenta o c´odigo gerado automaticamente a partir da execu¸c˜ao do procedimento (Tabela 4.6). As linhas 10 `a 14 definem o workflow especificado. As linhas 15 `a 20 representam o workflow desenvolvido na etapa de implementa¸c˜ao. O teste de valida¸c˜ao dos estados dos dois workflows ´e executado na linha 23. Igualmente, o teste de valida¸c˜ao das permiss˜oes ´e feito na linha 26. As linhas 28 `a 32 validam se os pap´eis definidos para as permiss˜oes est˜ao consistentes entre o workflow especificado e o workflow implementado.
Trecho de C´odigo 4.7: Script Python que realiza dos testes. 1 # -* - c o d i n g : utf -8 -* -
2 3 i m p o r t u n i t t e s t 4 f r o m r e a d i m p o r t * 5 6 c l a s s T e s t W o r k f l o w ( u n i t t e s t . T e s t C a s e ) : 7 8 def s e t U p ( s e l f ) : 9 # d e f i n i c o e s i n i c i a i s 10 s e l f . r e q u i s i t e s = g e t _ w o r k f l o w _ x m l ( ’ d a t a . xml ’ , F a l s e ) 11 s e l f . r e q u i s i t e s _ n a m e = s e l f . r e q u i s i t e s . get ( ’ w o r k f l o w _ n a m e ’ ) 12 s e l f . r e q u i s i t e s _ c o n t e n t = s e l f . r e q u i s i t e s . get ( ’ s t a t e s _ p e r m i s s i o n _ r o l e s ’ ) 13 s e l f . r e q u i s i t e s _ c o n t e n t _ s t a t e s = s e l f . r e q u i s i t e s _ c o n t e n t . k e y s () 14 s e l f . r e q u i s i t e s _ c o n t e n t _ p e r m i s s i o n s = s e l f . r e q u i s i t e s _ c o n t e n t . v a l u e s () [ 0 ] . k e y s () 15 # w o r k f l o w P l o n e 16 s e l f . d e f i n i t i o n = g e t _ w o r k f l o w _ x m l ( ’ d e f i n i t i o n . xml ’ , T r u e ) 17 s e l f . d e f i n i t i o n _ n a m e = s e l f . d e f i n i t i o n . get ( ’ w o r k f l o w _ n a m e ’ ) 18 s e l f . d e f i n i t i o n _ c o n t e n t = s e l f . d e f i n i t i o n . get ( ’ s t a t e s _ p e r m i s s i o n _ r o l e s ’ ) 19 s e l f . d e f i n i t i o n _ c o n t e n t _ s t a t e s = s e l f . d e f i n i t i o n _ c o n t e n t . k e y s () 20 s e l f . d e f i n i t i o n _ c o n t e n t _ p e r m i s s i o n s = s e l f . d e f i n i t i o n _ c o n t e n t . v a l u e s () [ 0 ] . k e y s () 21 22 def t e s t _ s t a t e s ( s e l f ) : 23 s e l f . a s s e r t I t e m s E q u a l ( s e l f . r e q u i s i t e s _ c o n t e n t _ s t a t e s , s e l f . d e f i n i t i o n _ c o n t e n t _ s t a t e s ) 24 25 def t e s t _ p e r m i s s i o n s ( s e l f ) : 26 s e l f . a s s e r t I t e m s E q u a l ( s e l f . r e q u i s i t e s _ c o n t e n t _ p e r m i s s i o n s , s e l f . d e f i n i t i o n _ c o n t e n t _ p e r m i s s i o n s ) 27 28 def t e s t _ p e r m i s s i o n s _ r o l e s ( s e l f ) : 29 for s t a t e in s e l f . r e q u i s i t e s _ c o n t e n t _ s t a t e s : 30 p e r m i s s i o n s = s e l f . r e q u i s i t e s _ c o n t e n t . get ( s t a t e ) 31 for p e r m i s s i o n , r o l e s in p e r m i s s i o n s . i t e m s () : 32 s e l f . a s s e r t I t e m s E q u a l ( roles , s e l f . d e f i n i t i o n _ c o n t e n t [ s t a t e ][ p e r m i s s i o n ]) 33 34 if _ _ n a m e _ _ == ’ _ _ m a i n _ _ ’ : 35 u n i t t e s t . m a i n ()
Ao executar o procedimento Executar Teste (Tabela 4.7) um erro ´e localizado. Esse corresponde a um erro de implementa¸c˜ao, onde o desenvolvedor atribuiu incorretamente pap´eis a uma respectiva permiss˜ao. Este erro ´e mostrado na Figura 4.13.
Figura 4.13: Execu¸c˜ao dos testes de valida¸c˜ao de workflow identificando um erro Ap´os a identifica¸c˜ao do erro, ´e aberto um ticket para o desenvolvedor efetuar a corre¸c˜ao. Conclu´ıda a corre¸c˜ao, o analista efetua um novo teste que n˜ao sinaliza diferen¸cas entre os requisitos iniciais e o workflow desenvolvido. A Figura 4.14 mostra que a execu¸c˜ao dos testes foi efetuado com sucesso.
Figura 4.14: Execu¸c˜ao dos testes de valida¸c˜ao de workflow sem identificar erros
4.7
Considera¸c˜oes Finais
Neste cap´ıtulo, foi apresentada uma proposta de teste funcional de um workflow Plone, procurando confrontar a especifica¸c˜ao de um workflow por um analista e a correta implementa¸c˜ao. Normalmente n˜ao existem testes automatizados para esta etapa da constru¸c˜ao em um portal Plone.
Essa proposta partiu de um conjunto de casos de uso que oferecem possibilidades de edi¸c˜ao da especifica¸c˜ao do workflow pelo analista. A seguir, o analista ou o desenvolvedor podem utilizar o produto implementado, workflow.validation, para mapear a especifica¸c˜ao em arquivos XML do pr´oprio workflow Plone. A partir deste mapeamento, essa proposta de solu¸c˜ao de teste foi por uma abordagem funcional que, a partir do pr´oprio mapeamento, gera automaticamente um conjunto de regras Unittest que valida o workflow Plone especificado contra o workflow Plone desenvolvido.
As etapas para o desenvolvimento do produto workflow.validation abrangeram a descri¸c˜ao dos casos de uso, a defini¸c˜ao do diagrama do banco de dados, do diagrama de classe, da arquitetura do framework workflow.validation e explica¸c˜oes dos principais trechos de c´odigos.
Para validar e experimentar a abordagem proposta, foi utilizado um cen´ario real de uso em que existem duas pessoas que ocupam os pap´eis de analista e
desenvolvedor. O fluxo de opera¸c˜ao para um cen´ario sem o produto de teste consistia simplesmente na defini¸c˜ao manual do workflow Plone, na etapa posterior de implementa¸c˜ao e no teste manual efetuado pelo analista, onde podiam ser constatado os erros. No entanto, o analista, juntamente com o desenvolvedor deveria testar todas as combina¸c˜oes poss´ıveis (caminhamentos) no grafo de estados e permiss˜oes para “cada um dos pap´eis definidos”, o que exigia um tempo consider´avel de teste, al´em de estar sujeito a erros humanos durante o processo.
O cen´ario de teste com o produto workflow.validation, exigiu apenas a especifica¸c˜ao do workflow Plone pelo analista, com uma etapa de mapeamento, gera¸c˜ao do c´odigo de teste e execu¸c˜ao do teste, mesmo antes da implementa¸c˜ao do workflow Plone. A partir do workflow.validation o analista pode detectar os erros de implementa¸c˜ao sem precisar definir exaustivamente e manualmente as permiss˜oes para todos os pap´eis definidos. Uma vez aprovado o workflow Plone, o desenvolvedor ter´a apenas a tarefa de adaptar o arquivo XML gerado `a aplica¸c˜ao Plone espec´ıfica.
5
CONCLUS ˜AO
O presente trabalho abordou quest˜oes relativas `a testes de software, a linguagem de programa¸c˜ao Python, ao servidor de aplica¸c˜ao Zope, ao gerenciador de conte´udo Plone e ao funcionamento de workflows Plone. A partir desses estudos foi encontrada uma limita¸c˜ao na abordagem de testes automatizados usados no Plone, essa limita¸c˜ao consiste na inviabilidade de realiza¸c˜ao de testes funcionais nas regras de workflow, ou seja, a realiza¸c˜ao de testes que permitam verificar se o desenvolvimento de um workflow Plone atende aos requisitos iniciais. Como solu¸c˜ao desse problema foi desenvolvido um produto (workflow.validation) Plone. O workflow.validation tem como principal objetivo validar se o workflow desenvolvido est´a coerente aos requisitos iniciais, sendo que essa valida¸c˜ao ´e efetuada atrav´es da automatiza¸c˜ao de testes funcionais. Destaca-se que o produto desenvolvido pode ser utilizado para validar qualquer workflow Plone.