A prática do desenvolvimento guiado por testes (do inglês, Test-Driven Development – TDD) preconiza que não é necessário criar um modelo detalhado das classes do software em desenvolvimento, pois os casos de teste criados em cada iteração servem de documentação sobre o escopo e as interfaces das classes do software (Janzen e Saiedian, 2008). Dessa forma, o primeiro passo do projeto e implementação do framework Guiwe foi definir que cada iteração seria responsável pela construção de uma classe. Essa decisão foi devido ao fato de que cada classe possui uma responsabilidade dentro do framework.
A construção das classes teve como base os passos dos ciclos TDD: criação de uma lista de casos de teste, implementação dos casos de teste, implementação das classes, execução do testes e refatoração. Para exemplificar esse processo, segue-se a descrição de como foi realizada a construção da classe HTMLDocument, que pertence à camada de interface gráfica. Essa classe é responsável por construir um documento HTML que possui um elemento span como sendo o raiz (principal). Esse elemento serve como um container para os demais elementos do documento e possui um atributo que o relaciona com o CSS que define a apresentação das páginas carregadas no painel principal da interface gráfica.
No projeto do framework Guiwe, foi definido que as listas de casos de teste devem conter as descrições e as assinaturas dos métodos da classe que está sendo construída. A descrição de um método indica o que deve ser testado e a sua assinatura define como se deseja que seja a sua interface. Por motivos de simplificação, construtores e métodos que apenas configuram ou retornam o valor de um atributo da classe não constam nas listas de casos de teste. Outro detalhe importante, a lista de
casos de testes sempre foi escrita no próprio arquivo Java da classe que estava sendo construída. Durante a implementação, as descrições dos métodos foram transformadas na documentação javadoc (Sun Mycrosystems, 2009f) e as assinaturas ganhavam o corpo do método. A classe HTMLDocument deve conter métodos para a inserção de elementos e para a obtenção do código do documento HTML que está sendo montado. A Figura 4.6 contém a lista de casos de teste da classe HTMLDocument.
Figura 4.6. Lista de Casos de Teste da classe HTMLDocument.
Ao invés de escrever todos os testes e, em seguida, implementar o código de todos os métodos e testá-los, optou-se por escrever os testes e implementar o código de um método por vez. Por exemplo, o método getContainer necessita de apenas um teste que verifica se o seu retorno é o elemento span do documento HTML. A implementação desse método contém somente uma instrução que retorna o primeiro elemento do documento HTML que, supostamente, deve ser o elemento span. A Figura 4.7(a) mostra o código do teste e a Figura 4.7(b) o código do método getContainer.
Após a implementação de um método, seus testes são executados. Caso ocorra um erro, a implementação deve ser corrigida até que passe pelo teste. Refatorações foram realizadas somente após a implementação de todos os métodos da classe. Vale salientar que alguns métodos não foram identificados durante a criação da lista dos casos de testes da sua classe e sua necessidade foi percebida somente durante a refatoração ou a construção de outra classe. Por exemplo, durante a refatoração da classe HTMLDocument, percebeu-se que seu código se tornaria mais flexível se existisse um método que retornasse o código HTML de um elemento e não somente de todo o documento. Assim, foi criado o método tagToString e o método toString passou a chamar esse método, informando como parâmetro o elemento raiz. A lista de casos de teste de uma classe também era alterada quando era detectada a necessidade de inserção de um novo método nessa classe. Um exemplo desse caso foi a criação do método
copyElement na classe HTMLDocument. Esse método permite criar uma cópia de um
elemento que pertence ao documento de outra instância de HTMLDocument e sua necessidade foi percebida durante a construção da classe PanelServlet.
As mensagens enviadas pela camada de interface gráfica para a de controle devem conter o nome da classe, o nome da operação a ser efetuada e os nomes e os valores dos atributos dessa classe. Essas informações são suficientes para que a classe
ConrollerPerformer crie um objeto da classe indicada com os valores dos atributos
configurados e efetue a operação. As operações possíveis correspondem àquelas determinadas pelo padrão Persistent Object (Yoder et al., 1998): salvar, atualizar, remover e recuperar o registro dos dados de um objeto na base de dados.
A criação e atribuição dos valores do objeto da classe indicada na mensagem é definida pelas classes ObjectManager e PersistentObjectManager. A classe
ObjectManager possui um método, chamado setFields, que recebe uma lista de nomes e
valores que devem ser atribuídos aos atributos de um objeto de qualquer classe e outro método, chamado getFields, que lê um objeto e retorna uma mensagem com os nomes e valores de seus atributos. Para que isso funcione, é imprescindível que os objetos tenham métodos getters e setters para todos os seus atributos. A Figura 4.8 apresenta o trecho de código do método getFields que obtém a lista de atributos (fields) de um objeto e invoca os métodos getters de cada um deles, acumulando seus nomes e valores na mensagem de resposta (result) no formato &nome_do_atributo=valor_do_atributo.
Figura 4.8. Trecho de código que obtém o nome e o valor dos atributos de um objeto.
A classe PersistentObjectManager é uma extensão de ObjectManager e inclui métodos que permitem buscar os registros da base de dados para, então, inseri-los em objetos que implementam o padrão PersistentObject. PersistentObjectManager também possui um método que retorna uma lista de registros da base de dados para ser utilizado na construção de tabelas na interface gráfica.