Gostaria de saber se tem como me ajudar a criar uma classe de teste para o seguinte código:
package br.com.bb.mdc.pdfbox;
import org.apache.pdfbox.multipdf.PDFMergerUtility;
import java.util.List;
import java.io.IOException;
import java.util.ArrayList;
public class PDFMerger {
public static void main(String[] args) throws IOException {
List<String> entradas = new ArrayList<String>();
entradas.add("C:\\Users\\t1077334\\Desktop\\mirrorfashion\\caelum-html-css-javascript-php.pdf");
entradas.add("C:/Users/t1077334/Desktop/mirrorfashion/caelum-java-objetos-fj11.pdf");
merge(entradas, "C:/Users/t1077334/Desktop/mirrorfashion/pdf_convertidos/arquivo.pdf");
}
public static void merge(List<String> entradas, String saida) throws IOException {
PDFMergerUtility saida1 = new PDFMergerUtility();
saida1.setDestinationFileName(saida);
for (String entrada : entradas) {
saida1.addSource(entrada);
}
saida1.mergeDocuments();
System.out.println("Sucesso");
}
}
Preciso criar um teste e ainda sou meio leigo no assunto.
Para começar, você precisa entender o básico dos testes:
- Para que serve um teste? Fundamentalmente, o teste tem como objetivo simular as situações reais (algumas não tão reais assim) a que determinada funcionalidade irá passar.
- Que tipo(s) de teste(s) existe(m)? Existem vários tipos de teste. Os mais comuns são os testes unitários, os testes integrados e as regressões (não, não é para saber que você foi rei/rainha na outra vida). Cada qual visa atender um determinado “pedaço” do sistema.
Particularmente (e isso significa que é meu entendimento e pode não condizer com a verdade), entendo que teste unitário deve ser aplicado à menor unidade testável de uma funcionalidade (pense que você desenvolveu uma calculadora. A menor unidade testável se refere a cada operação matemática implementada nesta calculadora). E só.
Ainda segundo o que eu entendo, teste integrado é aquele que faz o ponta a ponta, ou seja, começa onde o usuário vai manipular o sistema, vai até o mais baixo nível (não baixo calão, hein?) e volta ao usuário, especificamente sobre uma funcionalidade (caso de uso comprar passagem, desde a escolha do destino (uma funcionalidade aqui), da poltrona (outra aqui), até o cliente receber o aviso de passagem comprada (pode ser outra aqui, imprimir a passagem? Mais uma)).
E, por fim, a regressão é utilizada para testar todas as funcionalidades de um sistema (em alguns lugares, utiliza-se uma espécie adaptada, que testa só o que foi modificado. Eu acho essa abordagem perigosa, nem sempre se tem total domínio sobre o que está ou não interligado).
Dito isso, pergunto: que tipo(s) de teste(s) você quer criar? Quais são os requisitos que você precisa atender (e quais não)? Que erros podem ocorrer? Lembre-se, ao criar casos de teste, é preciso cobrir 100% das possibilidades, desde coisas corriqueiras, como não preencher campos obrigatórios até coisas bizarras, como o usuário clicar 20 vezes no botão, depois clicar numa label, depois mais 10 vezes na combo e aparecer um pentagrama virado para baixo e a imagem da besta na tela.
Ainda sobre quais testes você quer/precisa:
Eu desenvolvi uma calculadora. Preciso testar (testes unitários):
- Cada operação com valores válidos.
- Cada operação com valores inválidos (O que acontece se eu não informar um dos operandos? O que acontece se eu omitir o operador? O que acontece se eu informar zero como valor para divisor?)
Parece simples, mas, para 4 operações, eu tenho, no mínimo 8 testes (4 testes ok e 4 testes não ok). Isso, sem falar em regras específicas que eu queira validar. Assim, o número de testes sobe.
Ficou mais claro?
Poxa, depois de uma explicação dessa ficou muito mais claro pra mim agora.
Fui largado no estágio com a missão de realizar testes para essa função e não sabia nem por onde começar.
Preciso desenvolver testes unitários nessa função.
Consegui desenvolver alguns aqui e vou sentar com o meu chefe para uma revisão mais profunda nos códigos de teste que fiz.
Assim que tiver com os testes prontos, posto os códigos aqui.
Agradeço demais pela resposta.
Há grandes problemas no mundo e, talvez, a maioria nem se compare aos problemas que as pessoas que trabalham com desenvolvimento passam.
Eu levei anos para entender sobre como funcionavam os testes. Briguei muito com o JUnit e com coisas como Mockito, por, simplesmente, nunca ter sido apresentado de forma devida a eles.
O mesmo ocorreu com Maven e Spring Framework e várias outras tecnologias.
A que me refiro quando digo “apresentar de forma devida”?
Quero dizer que nunca me explicaram como eles poderiam ser utilizados, que contextos eles servem (e quais não atendem), etc.
Vi centenas de tutoriais, exemplos, step to step e etc, mas, cada qual aborda de uma maneira e, para quem está aprendendo, é uma dificuldade enorme entender conceitos e modos de uso.
Por isso, eu acredito que um estágio ou mesmo um contrato como jr deveria comportar, também, explicações sobre isso e não apenas “jogar pro estagiário/jr algo e ele que se vire”. Sou adepto da filosofia, que me foi ensinada um dia quando eu era jr, que prega que ao compartilhar conhecimento, a equipe perde meia hora de um, mas logo terá 2 para trabalhar e recuperar o tempo perdido.