Trabalho 2 - Tester

O Tester tem como objetivo permitir o teste do trabalho prático 2, de forma sistemática e uniforme para todos os grupos. Os alunos poderão testar a correção da sua implementação, usando o Tester.

Para executar o tester, os alunos com sistemas operativos Linux ou MacOS devem usar o script test-sd-tp2.sh, enquanto que os alunos com Windows 10 devem usar o script test-sd-tp2.bat.

Nota: Todos os ficheiros mencionados estão dispopíveis em: https://github.com/preguica/sd2122-tp-api.

Preparação

Antes de executar o tester e criar a imagem docker, devem adicionar e atualizar o fichero trab.props na raiz do vosso projeto com a informação correta:

USERS_REST_SERVER_MAINCLASS=classe do servidor Users REST (e.g. sd2122.tp2.server.RESTUsersServer)
USERS_REST_PORT=porto do servidor Users REST (e.g. 8080)
USERS_SOAP_SERVER_MAINCLASS=classe do servidor Users SOAP (e.g. sd2122.tp2.server.SOAPUsersServer)
USERS_SOAP_PORT=porto do servidor Users SOAP (e.g. 8080)
USERS_EXTRA_ARGS=parâmetro adicional a passar ao servidor Users, se algum
DIR_REST_SERVER_MAINCLASS=classe do servidor Directory REST (e.g. sd2122.tp2.server.RESTDirServer)
DIR_REST_PORT=porto do servidor Directory REST (e.g. 8080)
DIR_SOAP_SERVER_MAINCLASS=classe do servidor Directory SOAP (e.g. sd2122.tp2.server.SOAPDirServer)
DIR_SOAP_PORT=porto do servidor Directory SOAP (e.g. 8080)
DIR_EXTRA_ARGS=parâmetro adicional a passar ao servidor Directory, se algum
FILES_REST_SERVER_MAINCLASS=classe dos servidores Files REST (e.g. sd2122.tp2.server.RESTFilesServer)
FILES_REST_PORT=porto dos servidores Files REST (e.g. 8080)
FILES_SOAP_SERVER_MAINCLASS=classe dos servidores Files SOAP (e.g. sd2122.tp2.server.SOAPFilesServer)
FILES_SOAP_PORT=porto dos servidores Files SOAP (e.g. 8080)
FILES_EXTRA_ARGS=parâmetro adicional a passar aos servidores Files, se algum
DISCOVERY_MULTICAST_IP=endereço multicast para descoberta (e.g. 226.226.226.226)
DISCOVERY_MULTICAST_PORT=porto para descoberta (e.g. 2266)
USERS_SERVER_KEYSTORE=nome do ficheiro com o keystore do servidor Users (e.g. userserver.ks)
USERS_SERVER_KEYSTORE_PWD=password do keystore do servidor Users
DIR_SERVER_KEYSTORE=nome do ficheiro com o keystore do servidor Directory (e.g. dirserver.ks)
DIR_SERVER_KEYSTORE_PWD=password do keystore do servidor Directory
FILES_SERVER_KEYSTORE=nome do ficheiro com o keystore do servidor Files (e.g. filesserver.ks)
FILES_SERVER_KEYSTORE_PWD=password do keystore do servidor Files
CLIENT_TRUSTSTORE=nome do ficheiro com o truststore para os clienes (e.g. client-truststore.ks)
CLIENT_TRUSTSTORE_PWD=password do trustore
FILES_PROXY_SERVER_MAINCLASS=classe do servidor Proxy Files REST (e.g. sd2122.tp2.server.rest.DropboxFilesServer)
FILES_PROXY_PORT=porto do servidor Proxy Files REST (e.g. 8080)
FILES_PROXY_EXTRA_ARGS=argumentos extra a passar ao servidor PROXY Files
DIR_REP_SERVER_MAINCLASS=classe do servidor Directory REST, com replicação (e.g. sd2122.tp2.server.rest.RepDirServer)
DIR_REP_PORT=porto do servidor Directory REST, com replicação (e.g. 8080)
DIR_REP_EXTRA_ARGS_FIRST=argumentos extra a passar ao primeiro servidor replicado
DIR_REP_EXTRA_ARGS_OTHER=argumentos extra a passar ao outros servidores replicados

Enquanto não tiverem a parte SOAP implementada, devem deixar as propriedades respetivas sem nenhum valor, mas não as devem apagar. Podem igualmente testar o servidor Users sem terem os servidores Driectory e Files funcional, deixando a respetiva propriedade sem nenhum valor.

Devem adicionar ou atualizar o ficheiro Dockerfile presente na raiz do vosso projeto com o conteúdo presente no seguinte link: Dockerfile.

Sempre que alteram o vosso trabalho (incluindo o ficheiro trab.props) devem criar uma nova imagem Docker do vosso trabalho (usando o projeto Maven disponibilizado, tal consiste em executar: mvn clean compile assembly:single docker:build).

Execução dos testes

Para executar o Tester, basta executar o seguinte comando, usando o nome da imagem do vosso trabalho (substituir sd2122-tp2-xxxxx-yyyyy pelo nome da vossa imagem):

sh test-sd-tp2.sh -image sd2122-tp2-xxxxx-yyyyy

NOTA: há uma secção sobre problemas com a execução deste comando mais tarde neste documento.

Para mais informação, ver a página do Tester do trabalho 1.

Outras opções do Tester

O Tester possui algumas opções que podem ser especificadas ao corrê-lo, que modificam o seu comportamento.

• -test <num> : Permite omitir a execução de alguns testes. Por exemplo, se passarem o valor -test 2b, os testes começarão no teste 2b. Esta opção é útil quando já verificaram que o vosso trabalho funciona corretamente até um dado teste e estão a corrigir erros num teste específico.

• -sleep <seconds> : Permite diminuir o tempo de espera entre serem lançadas os containers com o vosso trabalho e iniciar a execução dos testes. Podem ajustar este valor consoante a capacidade do vosso computador e as operações que estejam a fazer na fase de inicialização.

• -log OFF|ALL|FINE|FINEST : Permite controlar o nível de mensagens gerado pelo programa. Por exemplo, ao usarem a opção -log FINE, o programa vai indicar todas as operações que está a fazer ao vosso sistema, indicando as mensagens recebidas e as esperadas, como se apresenta na imagem seguinte:

• -timeout seconds : Permite indicar os timeouts usados no vosso programa nos clientes de REST e SOAP (a indicação destes valores é importante para que a verificação do comportamento na presença de falhas funcione corretamente) – valor por omissão 10 segundos equivalente a -timeout 10.

• -dump true|false : Permite omitir as mensagens de erro dos servidor em caso de erro, usando -dump false.

• **-allProps true

  false** : Ignora verificação se todas as proriedades estão definidas.

• -interoptime miliseconds : Tempo entre duas operações sucessivas no proxy – use este valor caso tenha erros de demaidos pedidos, como formar de reduzir o número de pedidos por segundo efetuados ao servidor.

• -services true|false : Usando -services true, os serviços externos (Kafka, Zookeeper) são lançados em todos os testes.

• -kafkasleep seconds : Tempo de espera entre lançar os serviços externos - Kafka, Zoopkeeper - e lançar os servidores - valor por omissão 10 segundos.

• -failsleep seconds : Tempo de espera para descobrir que um servidor falhou - valor por omissão 15 segundos.

• -tokenvalid seconds : Tempo de validade dos tokens - valor por omissão 10 segundos.

Códigos de erro

Os códigos de erro que os vossos servidores devolvem devem estar de acordo com os comentários das respetivas interfaces, disponíveis em: https://github.com/preguica/sd2122-tp-api.

Versões

As versões do Tester são incrementais., i.e., a versão N do Tester executará todos os testes das versões anteriores. Nesta secção indicam-se as funcionalidades testadas por cada versão.

Versão 1

Testa as seguintes funcionalidades em REST, com apenas um servidor de ficheiro, usando TLS:

• Users: criação e leitura de utilizadores (102a)
• Users: atualização de utilizadores (102b)

• Users: remoção de utilizadores (102c)

• Directory: criação e leitura de ficheiros (103a)
• Directory: criação, leitura, remoção, share, unshare, ls (103b)
• Directory: delete user, acesso ficheiros (103c)

Testa as seguintes funcionalidades em SOAP, com apenas um servidor de ficheiro, usando TLS:

• Users: criação e leitura de utilizadores (104a)
• Directory: criação e leitura de ficheiros (104b)
• Directory: criação, leitura, remoção, share, unshare, ls (104c)
• Directory: delete user, acesso ficheiros (104d)

Testa as seguintes funcionalidades em REST/SOAP, com dois servidores de ficheiro, usando TLS:

• Directory: criação e leitura de ficheiros (105a)
• Directory: criação, leitura, remoção, share, unshare, ls (105b)
• Directory: delete user, acesso ficheiros (105c)

Testa as seguintes funcionalidades em REST, com um servidor de ficheiros proxy, usando TLS:

• Users: criação e leitura de utilizadores (106a)
• Directory: criação e leitura de ficheiros (106b)
• Directory: criação, leitura, remoção, share, unshare, ls (106c)
• Directory: delete user, acesso ficheiros (106d)

Versão 2

Testa as seguintes funcionalidades em REST, com apenas um servidor de ficheiro, usando TLS:

• Verifica se os ficheiros estão a ser gravados em disco, parando e reiniciando o servidor de ficheiros e verificando que ficheiros permanecem no servidor (107a).

Testa as seguintes funcionalidades em REST, com apenas um servidor de ficheiro Proxy, usando TLS:

• Verifica se flag de apagar ficheiros está implementado, parando e reiniciando o servidor de ficheiros proxy com flag para apagar ficheiros e verificando que ficheiros não estão no servidor (107b).
• Verifica se flag de apagar ficheiros está implementado, parando e lançando o servidor de ficheiros proxy com flag para não apagar ficheiros e verificando que ficheiros ainda estão no servidor (107c).

Testa as seguintes funcionalidades em REST, com três servidores de ficheiro, usando TLS:

• Directory: criação e leitura de ficheiros (108a)
• Directory: criação, leitura, remoção, share, unshare, ls (108b)
• Mix de operações, parando 1 servidor de ficheiros e executando operações (108c)
• Mix de operações, parando 1 servidor de ficheiros de cada vez, executando operações e reiniciando esse servidor antes de passar para o próximo (108d)
• Mix de operações, parando 2 servidor de ficheiros e executando operações - neste caso, dará suspect se não houverem operações que não conseguem ser executadas (108e)

NOTA: nestes testes, se uma operação de getFile falha, o Tester executá-la-á novamente uma vez. Espera-se que uma operação possa falhar por ter sido feito redirect para a réplica que falhou, assumindo-se que ao tentar fazer a leitura novamente o servidor de diretório fará redirect para outra réplica.

NOTA: podem usar o parâmetro -failsleep nsec no Tester para indicar quanto tempo o Tester deve aguardar até o vosso servidor de diretório ter detetado a falha dum servidor de ficheiros.

Testa as seguintes funcionalidades em REST, com três servidores de diretório (replicados) e três servidores de ficheiros, usando TLS:

• Directory: criação e leitura de ficheiros (109a)
• Directory: criação, leitura, remoção, share, unshare, ls (109b)

Versão 3

Testa as seguintes funcionalidades em REST, com três servidores de ficheiro, usando TLS:

• Mix de operações, parando 1 servidor de ficheiros e executando operações, incluindo escritas (108f)

Testa as seguintes funcionalidades em REST, com três servidores de diretório (replicados) e três servidores de ficheiros, usando TLS:

• Directory: criação, leitura, remoção, share, unshare, ls (109c)

Testa as seguintes funcionalidades em REST, com três servidores de diretório (replicados) e três servidores de ficheiros, usando TLS:

• Directory: criação, leitura, remoção, share, unshare, ls : falha de rede para a réplica 1 (110a)

• Directory: criação, leitura, remoção, share, unshare, ls : falha de rede para a réplica 2 (110b)

• Directory: criação, leitura, remoção, share, unshare, ls : crash na réplica secundária 1 (111a)
• Directory: criação, leitura, remoção, share, unshare, ls : crash na réplica secundária 2 (111b)
• Directory: criação, leitura, remoção, share, unshare, ls : crash na réplica secundária 1 e reinicia (111c)
• Directory: criação, leitura, remoção, share, unshare, ls : crash na réplica secundária 2 e reinicia (111d)
• Directory: criação, leitura, remoção, share, unshare, ls : crash na réplica primária (111e)
• Directory: criação, leitura, remoção, share, unshare, ls : crash na réplica primária e reinicia (111f)

Versão 4

Testa a utilização dos token nos seguintes cenários, usando TLS:

• Um servidor de diretório e um servidor de ficheiros, sem testar expiração (112a)
• Um servidor de diretório e um servidor de ficheiros, testando expiração (112b)
• Três servidores de diretório e três servidores de ficheiros, testando expiração (112c)

Testa as seguintes funcionalidades em REST, com três servidores de diretório (replicados) e três servidores de ficheiros, usando TLS:

• Execução de operações concorrentes (113a)

• Execução de operações concorrentes, com crash da réplica primária (113b)

• Atualizados os testes 103c, 104d, 105c, 106d.

Notas finais

O facto dum trabalho passar os testes todos (ou o teste duma funcionalidade) não equivale a que tenha a cotação máxima. Primeiro, devem ter em atenção que os testes apenas estão a testar as funcionalidades indicadas na listagem anterior. Segundo, a avaliação do trabalho terá em conta a qualidade do código.