Smalltalk – TDD

Como pode ser visto nos artigos anteriores, o ambiente do Smalltak (estou usando o Pharo) é excelente para o desenvolvimento e depuração, permitindo alterações em tempo de execução mantendo o estado dos dados. Nem precisa de TDD.

Mas não é bem assim. Alterações no sistema podem requerer que todos ou uma determinada série de testes sejam refeitas para validar a correção do programa. Quando o programador possui prazos e nao se policia muito bem, os testes impõem um limite tangível. Passou nos testes não é necessário mais nada. Também não é bem assim, mas vamos ignorar por hora.

O “video-tutorial-mudo” mostra como utilizar TDD no desenvolvimento e como o sistema facilita a vida do usuário na criação de classes, métodos e execução dos testes. Foram feitos apenas testes para passar, mas poderiam ser criados testes para os casos onde deve ocorrer falha (divisão por zero por exemplo) e, como sempre, outras coisinhas.

Inicialmente criamos uma classe derivada de TestCase que conterá os métodos correspondentes aos testes a serem efetuados. Existe ainda o método setUp que, se definido, será executado antes de cada teste e o método tearDown que será executado ao final. Colocamos os métodos na categoria testing.

No evento do vídeo abaixo, após a criação do primeiro método para o teste, eu poderia criar a variável ‘c’ na instância da classe e inicializá-la no método setUp. Optei por declará-la como temporária dentro do próprio método. Tudo que o ambiente não reconheceu, tentou criar de uma forma automatizada ou solicitar a confirmação.

Poderemos executar os testes diretamente pelo menu, toda a classe ou os métodos individualmente. Como de praxe, quando um teste falha, o círculo na esquerda fica vermelho. Se passa é mostrado na cor verde. Podemos utilizar a janela TestRunner para auxiliar na execução dos testes. Depois fizemos uma pequena refatoração no programa e executamos os testes novamente para confirmar se estava tudo perfeito.

O vídeo baseia-se na imagem salva do artigo anterior.

=-=-=-=-=
Powered by Blogilo

Smalltalk – Imagem e versionamento.

Para continuar lendo esta entrada, é necessário que você tenha lido a anterior. Pausa para ler a anterior……

Ok, então criamos uma classe, seus métodos, agrupamos para uma melhor organização, efetuamos os testes e, ao sair do ambiente, decidimos por salvar a imagem. Quando abrimos o ambiente novamente, ele encontra-se no mesmo estado que estava quando saímos. Podemos inclusive continuar com os testes no Workspace que tudo funcionará normalmente. Aliado ao fato de podermos efetuar alterações no código e continuar trabalhando como se nada tivesse acontecido, certamente são fatores que facilitam a vida do desenvolvedor.

Digamos que eu queira alterar o método resetTo: para que, se for recebido um valor negativo, inicialize o contador com zero. Não tem nenhum problema. Basta alterar o método e continuar com os testes (TDD fica para outra hora). Mas e se…. A sei. Você faz uma cópia do método ou comenta as linhas caso necessite retornar ao código original? Aqui não é necessário. O próprio ambiente se encarrega de fazer o versionamento do programa. A qualquer momento você poderá retornar algo anterior. Mais uma característica do ambiente para facilitar a vida do desenvolvedor.

Se fosse somente pela linguagem, Smalltalk seria apenas mais uma em um ambiente onde se cria uma nova linguagem a cada dia com algumas frescurinhas para diferenciar de outra. Mas como Smalltalk pressupõe a linguagem e o ambiente (já era assim na década de setenta) e o ambiente oferece facilidades não encontradas ou dificilmente encontradas em outros ambientes, aliados a uma linguagem simples e flexível, o seu estudo vale a pena. Se você possui um caixa razoável até poderia pensar em investir em um ambiente comercial (veja alguns casos de sucesso com o VisualWorks; e o JPMorgam não é o que se pode chamar de empresa pequena).

Ok, mais um vídeo mudo.

=-=-=-=-=
Powered by Blogilo

Smalltalk – Criação de classes, métodos e outras coisinhas.

Agora vamos ver como criar classe e métodos no Pharo. Como de praxe, ao final teremos um vídeo mudo. A primeira coisa a fazer é abrir o navegador do sistema para termos acesso a todas as classes e métodos existentes na nossa imagem de trabalho. Da esquerda para a direita temos as categorias das classes, classes, categorias dos métodos e métodos. Na parte inferior temos o código de um determinado método.

Depois falaremos mais sobre imagem. Para não bagunçar o sistema, criarei uma categoria chamada Sandbox onde vou criar classes para demonstração.

Depois crio uma classe Contador. Posteriormente, adiciono diversos métodos ao contador como incremento e decremento. Os métodos serão categorizados para que tudo fique mais ordenado e de fácil localização.

Ao criar o método para a inicialização da classe, foi informada uma variável que conterá o valor atual do contador propositadamente não definida anteriormente para mostrar como o ambiente se comporta nessas situações no momento em que ele compila o método (Accept).

No meio tempo, exploramos algumas possibilidades do ambiente como edit & continue com adição de novos métodos, inspeção do conteúdo de uma classe com o resultado da execução dos métodos.

Ao término iremos fechar a janela e salvar a imagem para uso futuro o que significa, basicamente, salvar o estado atual do ambiente. No próximo artigo veremos melhor o que significa isso.

Abaixo o vídeo-tutorial-mudo. 🙂

=-=-=-=-=
Powered by Blogilo

Smalltalk – Refactoring, Edit & Continue e outras coisinhas

Se no artigo anterior eu falei da busca por exemplo que eu acho legal no Smalltalk, nesse vou falar de outras coisinhas não só legais como importantes no desenvolvimento. Um dos aspectos interessantes/importantes é a possibilidade de editar o código em tempo de execução sem que seja necessário executar novamente a parte anterior. Ao final eu coloco um vídeo. Como não tenho microfone, o vídeo não tem som. A sequencia é, basicamente a seguinte:

• Chamo o método addOne para um número cuja finalidade seria de adicionar 1 ao número. Um simples incremento.
• Como o método não existe, o ambiente me informa e pede para que seja confirmado, cancelado ou corrigido. Ele abre uma janela com diversas opções que ele acha que poderia ser as correções.
• Se eu escolho informar que eu estava correto e o método não existe, o ambiente gera uma exceção para o erro com possibilidade para que eu continue, abandone, inicie a depuração ou crie o método.
• Decido por criar o método na classe Integer (já que eu havia aplicado para um inteiro), escolho a categoria arithmetic (serve para que os métodos fiquem agrupados de forma lógica) e os dados de quem está efetuando a alteração para que alguém seja considerado culpado em caso de problema. 😉
• É aberta uma janela para que eu edite o que o novo método irá fazer, informo que é apenas para somar 1 e retornar o resultado (usa-se ^ para indicar retorno de um valor), informo Accept para que o método seja compilado e seleciono Proceed para continuar o programa que estava sendo executado.

Ok, acabamos de ter o primeiro contado com o edit & continue, isto é, efetuamos uma alteração no programa e continuamos a execução sem a perda do que foi processado anteriormente. Na maioria das linguagens, se o seu programa está rodando a duas semanas, já processou um zilhão de dados e encontra um problema em uma circunstancia que não havia sido prevista inicialmente, a solução seria efetuar as correções e esperar mais duas semanas para chegar ao pondo em que havia parado. Em teoria, um programa em Smalltalk necessitaria ser interrompido apenas para a correção do bug e seguiria em frente. Outra opção radical, o que não significa racional, seria a possibilidade de colocar o sistema em produção logo após ter iniciado. Mas vamos juntar o Edit & Continue com o Refactoring.

• Agora eu resolvo invocar o método addOne para um valor em ponto flutuante. Novamente o ambiente irá mostrar um erro dizendo que não existe método addOne para a classe Float. Lógico, eu adicionei o método para a classe Integer. Poderia criar um novo método para a classe Float o que não seria muito inteligente. O ideal seria mover o método para a classe pai e ele seria herdado pelas filhas.
• Para fazer isso, posso abrir o navegador no ambiente, procurar o método addOne e movê-lo para a classe pai. Como pode ser visto nos menus do vídeo, as opção para refactoring são abundantes. Então escolho Refactor method e Pull up e pronto. O método passou da classe Integer para a classe Number. Digo para aceitar e pronto.

E assim termina o vídeo-tutorial-mudo de hoje. Lembrando que eu estou usando o Pharo versão 1.3. YMMV.

=-=-=-=-=
Powered by Blogilo