## Verificação e Validação de Software

### Professor:
José Campos

### Alunos:
João Lopes nº55812
Filipe Martins nº55814

# Assignment #6

Seguindo o caminho dos *assignments* passados, este *assignment* passa por realizar testes ao projeto JPass. JPass é uma aplicação *desktop* que visa apresentar uma forma simples e portátil com a qual um utilizador consegue fazer a gestão das suas palavras-passes. Juntamente com as palavras-passes guardadas é possível associar as mesmas a um nome e um URL entre muitas outras opções.

Este *assignment* passa pela realização de testes através da técnica *DataFlow Coverage* uma técnica de *White-Box testing*. *White-testing*, tal como a técnica *Black-testing*, passa por fazer testes ao código, sendo que a única diferença é que existe conhecimento sobre a código a ser testado, o *tester* tem acesso aos vários métodos e pode assim fazer testes mais específicos e personalizados.

*DataFlow Coverage* passa por considerar a forma como as variaveis podem ser definidas e/ou alteradas ou corrompidas no decorrer de uma função.
Para definir os testes a realizar será necessário identificar quais os *def-use pairs* que se enquandram com os critérios as verificar.

Os critérios que seram utilizados serão os seguintes:

* ***all-defs***
Este critério diz que para cada variável v, deve ser coberto pelo menos um *def-clear path* de cada definição de v para pelo menos um *c-use* ou um *p-use* de v. Por outras palavras, os casos de teste incluem um *def-clear path* de cada definição de v para alguma utilização (seja c-use ou p-use).

* ***all-c-uses***
Neste critério os casos de teste incluem um def-clear path de cada definição para todos os c-uses correspondentes.

* ***all-p-uses***
Neste critério os casos de teste incluem um def-clear path de cada definição para todos os p-uses correspondentes.

* ***all-uses***
Por fim este critéiro diz que os casos de teste incluem um def-clear path desde cada definição até cada uma das suas utilizações, incluindo tanto c-uses como p-uses.

Para a realização dos testes unitários utilizamos a ferramente JUnit, que é uma das ferramentas mais utilizadas na criação de testes unitários para Java.

## Função 1

Esta função tem como objetivo cortar uma `String` com mais de x caracteres e retornar uma `String`. A função recebe uma `String` como argumento e um número que ira servir para limite de carateres, a função ira depois verificar se a `String` tem ou não um número de caracteres superior ao que foi passado como parâmetro. Caso seja superior a mesma ira ser cortada e todos os caracteres depois do limite irão serão substituídos por '...' caso contrário é devolvida a `String` por inteiro.

    public static String stripString(String text, int length) {
        String result = text;
        if (text != null && text.length() > length) {
            result = text.substring(0, length) + "...";
        }
        return result;
    }

Depois de ser feita a análise à função foi realizado um data flow que descreve o percurso das diferentes variáveis da função StripString.


Como data flow permitiu criar vistas tabulares para todas as variáveis. Para cada variável foi possível identificar os def-uses, all-defs, all c-uses, all p-uses e all-uses.

* **Variavel text**

Para a variável text foi possível identificar 4 def-uses.


Para o critério *all-defs* e observando a tabela podemos verificar que o par número 1, onde a variável é definida na linha 1 e utilizada na linha 2, tendo o caminho <1,2>.


Seguidamente passamos para o critério all-p-uses, consegue-se confirmar que existem 2 opções válidas, sendo o par número 1 e 2, onde a variável é definida na linha 1 e utilizada na linha 2 com o caminho <1,2,5> e onde a variável é definida na linha 1 e utilizada na linha 4 com o caminho <1,2,3,4>, respetivamente.


Passando para o critério all-c-uses, consegue-se confirmar que existem novamente 2 opções válidas, sendo o par número 3 e 4, onde a variável é definida na linha 1 e utilizada na linha 3 com o caminho <1,2,3> e onde a variável é definida na linha 1 e utilizada na linha 3 com o caminho <1,2,3,4>, respetivamente.


Por fim relativamente ao critério ***all-uses***, todos os pares são validos.


* **Variavel length**

Para a variável text foi possível identificar 3 def-uses.


Para o critério *all-defs* e observando a tabela é possível verificar que o par número 2, onde a variável é definida na linha 1 e utilizada na linha 3, tendo o caminho <1,2,3>.


Relativamente ao critério all-p-uses, existe apenas uma opção, sendo o par número 1, onde a variável é definida na linha 1 e utilizada na linha 4 com o caminho <1,2,3,4>.


Passando para o critério all-c-uses, consegue-se confirmar que existem 2 opções válidas, sendo o par número 2 e 3, onde ambas as variáveis são definidas na linha 1 e utilizadas na linha 3 com o caminho <1,2,3>.


Por fim relativamente ao critério ***all-uses***, todos os pares são validos.


* **Variavel result**
Para a variável text foi possível identificar 3 def-uses.


Para o critério *all-defs* e observando a tabela é possível verificar que o par número 1, onde a variável é definida na linha 2 e utilizada na linha 4, tendo o caminho <2,3,4>.


Para o critério *all-defs* não existe nenhuma variável.

Passando para o critério *all-c-uses* foi possível verificar todos os pares definidos são validos:
* O par 1, onde a variável é definida na linha 1 e utilizada na linha 4, tendo o caminho <2,3,4>.
* O par 2, onde a variável é definida na linha 1 e utilizada na linha 5, tendo o caminho <1,2,3,5>.
* O par 3, onde a variável é definida na linha 4 e utilizada na linha 5, tendo o caminho <4,5>.
*

Por fim relativamente ao critério ***all-uses***, todos os pares são validos.

### Testes realizados

De forma a poder testar os pares para cada critério, foram realizados 4 testes. Após a sua execução foi possível verificar que o comportamento estava de acordo com o que era previsto.

## Função 2

Esta função escolhida para realizar os testes é a função setClipboardContent(String str), esta função tem como objetivo receber uma string e definir a mesma no System ClipBoard.

public static void setClipboardContent(String str) throws Exception {
        if (str == null || str.isEmpty()) {
            clearClipboardContent();
            return;
        }
        try {
            StringSelection selection = new StringSelection(str);
            Toolkit.getDefaultToolkit().getSystemClipboard().setContents(selection, selection);
        } catch (Throwable throwable) {
            throw new Exception("Cannot set clipboard content.");
        }
    }

Depois de ser feita a análise à função foi realizado um data flow que descreve o percurso das diferentes variáveis da função setClipboardContent.
Neste caso foi possível identificar as duas variaveis presentes na função, uma `String` chamada *str* e uma `StringSelection` chamada *selection*.


Através do data flow realizado foi possivel identificar os *def-use pairs* de ambas as variaveis.

* **Variavel str**

Relativamente a variavel *str* conseguimos identificar 3 *def-use pairs*, onde constam a definição da variavel, um *p-use* e um *c-use*.


Utilizando o critério ***all-defs*** e observando a tabela podemos observar que qualquer um dos três pares é valido, tendo sido escolhido o par número 3, onde a variavel é definida na linha 1 e utilizada na linha 5, tendo o caminho <1,2,5>.


Passando para o critério ***all-c-uses*** foi possivel verificar que só um dos pares definidos é valido, sendo o par número 3, onde a variavel é definida na linha 1 e utilizada na linha 5, tendo o caminho <1,2,5>.


De seguida temos o critério ***all-p-uses***, onde identificamos dois pares validos, o par numero 1 e o par numero 2, pares que correspondem aos dois possiveis resultados da condição if.


Por fim relativamente ao critério ***all-uses***, todos os pares são validos.


* **Variavel selection**

Relativamente a variavel *selection* só foi possivel identificar 1 *def-use pairs*.


### Testes realizados

Após a definição dos pares para cada critério foram criados diversos testes de modo a verificar o funcionamento da função. Foram criados 3 testes, de modo a validar os critérios definidos. Após a sua execução foi observado que o seu comportamento estava de acordo com o previsto.

## Função 3

O Propósito da função `createFormatter` é de através de um padrão de datas do tipo `String` recebido como parâmetro, ex. (01-01-2010), caso este seja valido, transformá-lo num objeto do tipo `DateTimeFormatter` de modo a formatar datas do tipo `DateTime`.

public static DateTimeFormatter createFormatter(String format){
        DateTimeFormatter formatter;
        try {
            formatter = DateTimeFormatter.ofPattern(format);
        } catch (IllegalArgumentException | NullPointerException e) {
            LOG.log(Level.WARNING, String.format("Could not parse date format [%s] due to [%s]", format, e.getMessage()));
            formatter = DateTimeFormatter.ISO_DATE;
        }
        return formatter;
    }

Depois de ser feita a análise à função foi realizado um data flow que descreve o percurso das diferentes variáveis da função createFormatter.
Neste caso foi possível identificar as duas variaveis presentes na função, uma `String` chamada *format* e um `DateTimeFormatter` chamado *formatter*.


Através do data flow realizado foi possivel identificar os *def-use pairs* de ambas as variaveis.

* **Variavel format**

Relativamente a variavel *format* conseguimos identificar 2 *def-use pairs*, onde constam a definição da variavel e dois *c-use*.


Utilizando o critério *all-defs* e observando a tabela podemos observar que qualquer um dos dois pares é valido, tendo sido escolhido o par número 2, onde a variavel é definida na linha 1 e utilizada na linha 4, tendo o caminho <1,2,4>.


Passando para o critério *all-c-uses* foi possivel verificar que só um dos pares definidos é valido, sendo o par número 2, onde a variavel é definida na linha 1 e utilizada na linha 4, tendo o caminho <1,2,4>.


De seguida temos o critério *all-p-uses*, onde, visto que não existe nenhum *p-use* nesta função não foi possivel utiliza-lo.

Por fim relativamente ao critério *all-uses*, ambos os pares são validos.


* **Variavel formatter**

Relativamente a variavel *formatter* conseguimos identificar 2 *def-use pairs*, onde constam duas definições da variavel e um *c-use*.


Utilizando o critério *all-defs* e observando a tabela podemos observar que qualquer um dos dois pares é valido, tendo sido escolhido o par número 2, onde a variavel é definida na linha 3 e utilizada na linha 6, tendo o caminho <3,6>.


Passando para o critério *all-c-uses* foi possivel verificar que ambos o pares definidos são validos, tendo sido escolhido o par número 2, onde a variavel é definida na linha 3 e utilizada na linha 6, tendo o caminho <3,6>.


De seguida temos o critério *all-p-uses*, onde, visto que não existe nenhum *p-use* nesta função não foi possivel utiliza-lo.

Por fim relativamente ao critério *all-uses*, ambos os pares são validos.


### Testes realizados

Após a definição dos pares para cada critério foram criados diversos testes de modo a verificar o funcionamento da função. Foram criados 2 testes, de modo a validar os critérios definidos. Após a sua execução foi observado que o seu comportamento estava de acordo com o previsto.