Blog da Thânia Clair

Por acaso você também é daquelas pessoas que perdem ou perderiam um dia inteirinho pra deixar sua página um pouco mais elegante? Pequenas mudanças de cor, de tamanho, padding, margin e imagens que às vezes fazem a diferença para você e para os olhos de alguns, mas para a maioria simplesmente não faz a menor diferença. Sinceramente, às vezes acho que estou no curso errado em relação a esse quesito. Quase não posso acreditar quando vou à aula e assisto àquelas apresentações em Power Point totalmente preto e branco… Fala sério! Como é que tem gente que tem essa coragem! Não tem um pingo de capricho e ainda por cima não querem que a gente durma nas apresentações deles… Enfim, às vezes venho pra casa decepcionada. É incrível como pessoas da área de tecnologia não tem a menor noção de cor, tamanho e espaço. Nossa, só de escrever fico indignadíssima! Decepcionante…

Tá, eu admito, eu sofro desse mal. Pequenas coisas coloridas me chamam muito atenção e sou capaz de perder horas em cima delas, principalmente quando eu estou com preguiça de fazer o que interessa. Na verdade, às vezes é meio que inconciente. Estou fazendo certas coisas e sem querer querendo me empolgo com essas coisas, quando vejo a hora passou e nem adianta mais tentar continuar o ritmo. Enfim, pelo menos são alguns momentos de alegria.

A minha façanha de hoje começou quando eu fui corrigir meu TCC. Eu tinha feito uma tabelinha muito legalzinha em latex que representava os diagramas presentes nas versões de UML 1 e 2. É verdade que ela estava um pouco sem graça mas o Ricardo, meu orientador, disse que “não tava legal”. :’(

Bom, comecei a incrementá-la e colocar as coisas que ele tinha pedido. Realmente não queria simplesmente copiar a tabela do livro dele. Queria mesmo é ter conseguido deixar o background colorido mas não funcionou. Acho que esqueci de alguma pacote, só pode ser. Aqui na minha máquina simplesmente não funciona o \rowcolor, muito menos o \columncolor. Ainda vou descobrir qual foi o problema, mas por enquanto me contentei com colorir as fontes. Essa brincadeira levou umas 3 horas, mas eu me divirto. Olha como ficou a tabela em latex:

\begin{table}[ht!]
\begin{center}
    \setlength{\belowcaptionskip}{10pt} % espaço entre caption e tabela
    \caption{Comparação geral entre os diagramas da primeira e segunda versão de UML.}
    \footnotesize {
    \begin{tabular}{|p{2cm}||p{6cm}|c|c|}
        \hline
        \hline
        \textbf{Modelagem } & \textbf{Diagrama} & \textbf{UML 1} & \textbf{UML 2} \\ 
        \hline
        \hline
        \multirow{6}{*}{\textbf{Estrutural}} 
        & Diagrama de Classes                   & \textcolor{darkgreen}{V} & \textcolor{darkgreen}{V} \\
        & Diagrama de Objetos                   & \textcolor{darkgreen}{V} & \textcolor{darkgreen}{V} \\
        & \textcolor{blue}{Diagrama de Pacotes} & \textcolor{red}{X} & \textcolor{darkgreen}{V} \\
        & \textcolor{blue}{Diagrama de Estrutura Composta} & \textcolor{red}{X} & \textcolor{darkgreen}{V} \\
        & Diagrama de Componentes               & \textcolor{darkgreen}{V} & \textcolor{darkgreen}{V} \\
        & Diagrama de Utilização                & \textcolor{darkgreen}{V} & \textcolor{darkgreen}{V} \\
        \hline
        \multirow{9}{*}{\textbf{Dinâmica}}
        & Diagrama de Casos de Uso             & \textcolor{darkgreen}{V} & \textcolor{darkgreen}{V} \\
        & Diagrama de Seqüência                & \textcolor{darkgreen}{V} & \textcolor{darkgreen}{V} \\
        & Diagrama de Comunicação              & \textcolor{red}{X} & \textcolor{darkgreen}{V} \\
        & Diagrama de Colaboração \textbf{*}   & \textcolor{darkgreen}{V} & \textcolor{red}{X} \\
        & Diagrama de Máquina de Estados       & \textcolor{red}{X} & \textcolor{darkgreen}{V} \\
        & Diagrama de Statechart \textbf{**}   & \textcolor{darkgreen}{V} & \textcolor{red}{X} \\ 
        & Diagrama de Atividades               & \textcolor{darkgreen}{V} & \textcolor{darkgreen}{V} \\
        & \textcolor{blue}{Diagrama de Visão Geral de Interação} & \textcolor{red}{X} & \textcolor{darkgreen}{V} \\
        & \textcolor{blue}{Diagrama de Temporização}             & \textcolor{red}{X} & \textcolor{darkgreen}{V} \\
        \hline
    \end{tabular}
    }
    \label{tab:diagramas}
\end{center}
\end{table}

\begin{table}[ht!]
\begin{center}
    \setlength{\belowcaptionskip}{10pt} % espaço entre caption e tabela
    \scriptsize {
    \begin{tabular}{ p{0.2cm} p{7cm} }
        \textsc{\textbf{Legenda:}} & \\
        \textcolor{darkgreen}{V} & Existência do diagrama \\
        \textcolor{red}{X}       & Ausência do diagrama \\
        \textcolor{blue}{O}      & Diagrama novo em UML 2 \\
        \textbf{*}  & Denominado \textbf{diagrama de comunicação} em UML 2. \\ 
        \textbf{**} & Denominado \textbf{diagrama de máquina de estados} em UML 2. \\ 
     \end{tabular}
    }
\end{center}
\end{table}

O resultado foi esse:

Gostou? Bom, não tem nada de mais. A coisa diferente do básico de uma tabela em latex foi a tag \textcolor que dá cor a fonte do texto. A segunda tabela acho que não precisava existir, mas não encontrei um recurso que fizesse o que eu queria. Enfim, fica assim por enquanto.

=)

Oba, fim de semana!

Seria um pouco mais agradável se eu não tivesse que corrigir o texto do meu TCC. Enfim..

Pra aqueles que estão cheios de coisas pra fazer no computador, mesmo com aquele sol lindo batendo lá fora, segue a tirinha do garfield de hoje pra animar o dia:

Enjoy!

Fonte: Garfield Comic Today

Acredite, muitos testes de unidade não são tão triviais. Realmente, hoje foi o dia… :’(

O problema começou quando percebi que eu não queria que todas as variáveis de instância do meu teste fossem inicializadas no meu método setUp() (com a anotação @Before), já que este método é executado antes de todo método com a anotação @Test. Na verdade, eu queria que ele fosse executado uma vez só. Bom, eu tinha duas alternativas, ou inicializar cada variável de instância na declaração (ferindo o code standards) ou trocar a anotação para @BeforClass. Eu troquei a anotação mas só depois eu percebi que o o framework JUnit não permite um método com @BeforeClass que não seja estático. Mas eu queria inicializar variáveis, como eu ia fazer isso em um método estático? Bom, conversei com meu team leader (Mestre Ota) e ele me disse pra optar pela solução mais óbvia (eu sinceramente achei que tinha uma solução melhor): transformar as variáveis de instância em estáticas. Segundo ele, essa coisa do framework JUnit “forçar” os métodos com @BeforeClass a serem estáticos é uma característica importante para quando vários testes são executados em paralelo, assim o framework não teria sempre que recriar as instâncias. Ainda não me convenceu muito, mas pelo menos ajudou a solucionar o problema.

Alguns programadores dizem que não é legal ficar chamando um método com this. Inclusive, o pessoal no Labsoft/Motorola não gosta muito (pelo menos os que inspecionam meu código), mas eu particularmente gosto bastante. Até hoje eu abominava estas pessoas. Foi então que eu descobri que o Eclipse (Europa) não remove automaticamente os this - pelo menos eu não encontrei a opção. Bom, então vocês podem deduzir que quando eu tranformei as minhas variáveis de instância em variáveis de classe, vários warnings começaram a aparecer… Fiquei procurando um refactoring automático, mas o Eclipse só me mostrava um “Remove static modifier” . Droga, tive que remover todos os this na mão - e olha que não eram poucas linhas de código. :/

Falando em testes de unidade, não custa ressaltar que na versão anterior do JUnit, existiam dois métodos, setUp() e tearDown(), que eram utilizados para configurar o ambiente de teste antes e depois da execução de cada suite. Como eu postei antes, o JUnit 4 substituiu estes métodos por duas anotações, @Before e @After. Bom, qual a diferença?!? A diferença é que agora ganhamos uma flexibilidade maior para definirmos os nomes dos métodos de inicialização da unidade de teste visto que o framework agora faz interpretações a partir das anotações. Agora a gente pode dar o nome que a gente quiser para o método - caso a gente tenha criatividade, heheheh…

A API do JUnit é rica em assertivas para testes de unidade. Eu sei que existe Eclipse e control + space, mas às vezes é bom ter as coisas em mente (ainda que ter um compilador na cabeça é perfeito pra tirar certificações). São elas:

• assertEquals(expected, actual)
• assertEquals(message, expected, actual)
• assertEquals(expected, actual, delta)
• assertEquals(message, expected, actual, delta)
• assertFalse(condition)
• assertFalse(message, condition)
• assertNotNull(object)
• assertNotNull(message, object)
• assertNotSame(expected, actual)
• assertNotSame(message, expected, actual)
• assertNull(object)
• assertNull(message, object)
• assertSame(expected, actual)
• assertSame(message, expected, actual)
• assertTrue(condition)
• assertTrue(message, condition)
• fail()
• fail(message)
• failNotEquals(message, expected, actual)
• failNotSame(message, expected, actual)
• failSame(message)

=)

Hey!

A tirinha do Calvin and Hobbes de hoje está muito boa! Pra você que ainda não é um viciado e não lê todo dia, confira:

Fonte: http://www.gocomics.com/calvinandhobbes/

O JUnit é um framework de código aberto que dá suporte à criação de testes de software na linguagem Java.

Em Java, anotação é uma maneira de se adicionar metadados ao código Java que pode ficar também disponível para o programador em tempo de execução. Pode ser considerada uma tecnologia alternativa ao XML.

Os testes de unidade escritos com JUnit utilizam algumas anotações de uso geral. Não são muitas e por isto convém tê-las em mente ao se codificar um teste. Para utilizá-las é preciso importar as classes referentes no pacote org.junit. Seguem as anotações:

• @Test: Indica que o método anotado contém testes.
• @After: Identifica método para ser executado após cada método de teste, indicado pela anotação @Test.
• @AfterClass: Identifica método para ser executado após a execução de todos os métodos de teste da classe em questão. Em outras palavras, é executado uma única vez para cada instância da classe de teste, após a execução de todos os métodos de teste.
• @Before: Identifica método a ser executado antes da execução de todo método de teste. Em outras palavras, será executado quantas vezes forem o número de métodos de teste.
• @BeforeClass: Identifica método que será executado uma única vez por instância da classe que contém os testes e antes da execução de qualquer método de teste.

Anotações em testes de unidade com JUnit são úteis para indicar as atividades que devem ser executadas em momentos distintos da execução dos testes.

Enjoy!