{"id":23284184,"url":"https://github.com/tst-labs/test-unit","last_synced_at":"2025-08-21T16:32:30.700Z","repository":{"id":36381464,"uuid":"158744708","full_name":"tst-labs/test-unit","owner":"tst-labs","description":"Projeto que oferece funcionalidades de auxílio no desenvolvimento de testes.","archived":false,"fork":false,"pushed_at":"2024-07-29T06:10:59.000Z","size":508,"stargazers_count":3,"open_issues_count":6,"forks_count":2,"subscribers_count":8,"default_branch":"master","last_synced_at":"2024-08-09T17:14:50.288Z","etag":null,"topics":["cdi","it","jpa","junit","tests"],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/tst-labs.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2018-11-22T19:53:36.000Z","updated_at":"2024-04-09T03:00:58.000Z","dependencies_parsed_at":"2023-11-10T20:37:52.555Z","dependency_job_id":null,"html_url":"https://github.com/tst-labs/test-unit","commit_stats":null,"previous_names":[],"tags_count":12,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tst-labs%2Ftest-unit","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tst-labs%2Ftest-unit/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tst-labs%2Ftest-unit/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tst-labs%2Ftest-unit/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/tst-labs","download_url":"https://codeload.github.com/tst-labs/test-unit/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":230523775,"owners_count":18239437,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cdi","it","jpa","junit","tests"],"created_at":"2024-12-20T01:38:36.610Z","updated_at":"2024-12-20T01:38:37.111Z","avatar_url":"https://github.com/tst-labs.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"TEST Unit\n==============================\n\n[![Build Status](https://travis-ci.org/tst-labs/test-unit.svg?branch=master)](https://travis-ci.org/tst-labs/test-unit)\n\nBiblioteca que auxilia no desenvolvimento de testes unitários e de integração.\n\n- Evita o retrabalho relacionado à configuração de diversas ferramentas utilizadas, como _CDI_, _DBUnit_ e _JPA_.\n- Fornece algumas funcionalidades adicionais, como medição do tempo de execução de cada etapa do teste (inicialização de frameworks, carga de banco de dados, etc).\n- É extensível. \n\nInicialmente prospectada como uma biblioteca privada do TST e nomeada **TST Unit**, seu código foi aberto em 2018, passando a se chamar **TEST Unit**.\n\nHistórico de mudanças\n----------\n\n**xx/07/2023 - 3.0.0**\n- ![Melhoria][melhoria] _[Core]_ Atualizando para Java 17\n- ![Melhoria][melhoria] _[Mockito]_ Atualizando para Mockito 5.4.0\n\n**17/12/2019 - 2.0.0**\n- ![Melhoria][melhoria] _[CDI]_ Atualizando dependência do _CDI-Unit_ para **4.1.0**.\n\n**04/04/2019 - 1.0.0**\n- ![Novo][novo] Primeiro release do projeto.\n\n\n[bug]: docs/bug.png\n[melhoria]: docs/improvement.png\n[novo]: docs/new-feature.png\n\nRequisitos\n---------\n\n* JDK 8+\n\nUso\n----------\n\nPara utilizar o TEST Unit em seu projeto, adicione o módulo abaixo como dependência:\n\n```xml\n\u003cdependency\u003e\n    \u003cgroupId\u003ebr.jus.tst\u003c/groupId\u003e\n    \u003cartifactId\u003etest-unit-core\u003c/artifactId\u003e\n    \u003cversion\u003e[1.0.0,)\u003c/version\u003e\n    \u003cscope\u003etest\u003c/scope\u003e\n\u003c/dependency\u003e\n```\n\nE então, utilize a classe `TSTUnitRunner` para rodar seus testes:\n\n```java\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\npublic class MinhaClasseTeste {\n\n    @Test\n    public void teste() {\n        // ...\n    }\n}\n```\nSem mais nenhuma configuração adicional, seu teste passa a contar com alguns recursos básicos, como a impressão dos nomes dos testes que estão rodando:\n\n```\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e Executando: br.jus.tst.teste.MinhaClasseTeste.teste \u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\n```\n\nPara utilizar outros recursos, você pode adicionar extensões, que adicionam novas funcionalidades ao TEST Unit.\n\n### Customização\n\nO recurso que imprime o nome de cada teste no console pode ser desativado ou customizado através da anotação `@ImprimirNomeTeste`.\n\nO valor padrão, que é utilizado quando nenhuma anotação `@ImprimirNomeTeste` está presente na classe de testes, pode ser configurado através de um arquivo `testunit.properties` em seu _classpath_:\n\n```\n# Desabilita a impressão dos nomes dos testes por padrão\ncore.printtestname.default=false\n```\n\n### Medição do tempo de execução\n\nExiste um recurso que permite visualizar o tempo de execução gasto em cada uma das etapas do teste. Isso é útil principalmente quando seu teste utiliza muitas extensões e o tempo total de execução esteja ficando muito alto.\n\nPara habilitar (e customizar) esse recurso, basta configurar através do arquivo `testunit.properties`:\n\n```\n# Habilita o Medidor de Tempo de Execução\ncore.medidortempoexecucao.habilitado=true\n# Customiza a mensagem que é exibida no console - normalmente não é necessário alterar\n# core.medidortempoexecucao.mensagens.formato=\\n[TST UNIT - MEDIDOR] %s levou %d milisegundos\\n\n# Indica se as mensagens devem ser geradas em formato ANSI (com cores, por exemplo)\n# core.medidortempoexecucao.consoleansi=true\n# Define um tempo (milisegundos) a partir do qual a execução de determinada operação é considerada no nível \"alerta\"\n# core.medidortempoexecucao.duracao.alerta=500\n# Define um tempo (milisegundos) a partir do qual a execução de determinada operação é considerada no nível \"perigo\"\n# core.medidortempoexecucao.duracao.perigo=1000\n```\n\nAssim, ao executar seus testes, você verá no console informações como:\n\n```\n[TST UNIT - MEDIDOR] XXX levou 901 milisegundos\n\n[TST UNIT - MEDIDOR] YYY levou 500 milisegundos\n\n[TST UNIT - MEDIDOR] ZZZ levou 15 milisegundos\n\n```\n\nCaso a propriedade `core.medidortempoexecucao.consoleansi` tenha valor `true`, os valores referentes aos tempos de execução serão impressos com cores para indicar se o tempo ultrapassou os valores definidos como _alerta_ ou _perigo_.\n\n### Utilizando em projetos com versões inferiores ao Java 8\n\nÉ possível ter um projeto Maven em que o código de produção use uma versão do Java diferente do código dos testes. Para isso, é necessário configurar o `maven-compiler-plugin` conforme abaixo (solução retirada do [StackOverflow](http://stackoverflow.com/a/38743953/3228529)):\n\n```xml\n\u003cplugin\u003e\n    \u003cgroupId\u003eorg.apache.maven.plugins\u003c/groupId\u003e\n    \u003cartifactId\u003emaven-compiler-plugin\u003c/artifactId\u003e\n    \u003cversion\u003e3.5.1\u003c/version\u003e\n    \u003cconfiguration\u003e\n        \u003csource\u003e1.7\u003c/source\u003e\n        \u003ctarget\u003e1.7\u003c/target\u003e\n        \u003ctestSource\u003e1.8\u003c/testSource\u003e\n        \u003ctestTarget\u003e1.8\u003c/testTarget\u003e\n    \u003c/configuration\u003e\n\u003c/plugin\u003e\n```\n\nNeste exemplo, o código de produção utiliza Java 7, enquanto que os testes serão compilados com Java 8.\n\nAinda assim, caso tente rodar os testes diretamente de sua IDE, pode ser que ela tente utilizar nos testes a versão do Java definida para o projeto. No caso do Eclipse, isso pode ser alterado conforme abaixo:\n\n1. Clicando com o botão direito do mouse sobre o projeto, ir em _Run As \u003e Run Configurations..._.\n2. Dentro do item _JUnit_, clicar sobre seu testes.\n3. Acessar a aba _JRE_.\n4. Marcar _Execution environment_ e selecionar a opção referente ao _JavaSE 1.8_.\n5. Salvar e rodar o teste.\n\n### Extensões\n\n![Arquitetura do projeto](docs/Arquitetura.png)\n\nAs extensões atualmente existentes são:\n\n* _test-unit-cdi_: habilita o uso de [CDI](http://weld.cdi-spec.org/) nos testes (obs.: como muitas vezes o uso de CDI é feito em conjunto com mocks, o Mockito também já é habilitado por padrão através dessa extensão, não sendo necessário o uso da _test-unit-mockito_);\n* _test-unit-dbunit_: habilita o uso do [DBUnit](http://dbunit.sourceforge.net/) nos testes;\n* _test-unit-mockito_: habilita o uso do [Mockito](http://mockito.org/) nos testes;\n* _test-unit-jpa_: habilita o uso de JPA nos testes.\n\nPara usar uma extensão, basta adicionar a respectiva dependência ao seu projeto:\n\n```xml\n\u003cdependency\u003e\n    \u003cgroupId\u003ebr.jus.tst\u003c/groupId\u003e\n    \u003cartifactId\u003etest-unit-dbunit\u003c/artifactId\u003e\n    \u003cversion\u003e[1.0.0,)\u003c/version\u003e\n    \u003cscope\u003etest\u003c/scope\u003e\n\u003c/dependency\u003e\n```\n\nCada extensão define uma anotação que pode ser incluída em suas classes de testes para ativá-la:\n\n```java\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\n@HabilitarXxx\npublic class MinhaClasseTeste {\n\n    @Test\n    public void teste() {\n        // ...\n    }\n}\n```\n\n#### TEST Unit CDI\n\nHabilita o CDI nos testes. Observar que as precondições para funcionamento do CDI devem ser seguidas (como ter um `beans.xml` no seu _classpath_). Por comodidade, essa extensão já habilita o uso do Mockito nos testes. É utilizado o [Weld](http://weld.cdi-spec.org/) como implementação do CDI.\n\nA maior parte do funcionamento é delegado para o [CDI Unit](http://jglue.org/cdi-unit/).\n\n##### Dependência\n\n```xml\n\u003cdependency\u003e\n    \u003cgroupId\u003ebr.jus.tst\u003c/groupId\u003e\n    \u003cartifactId\u003etest-unit-cdi\u003c/artifactId\u003e\n    \u003cversion\u003e[1.0.0,)\u003c/version\u003e\n    \u003cscope\u003etest\u003c/scope\u003e\n\u003c/dependency\u003e\n```\n\n##### Uso\n\nAlém da anotação `@HabilitarCdiAndMockito`, as anotações do CDI Unit podem ser usadas normalmente. Ver [CDI Unit User Guide](http://jglue.org/cdi-unit-user-guide/).\n\n```java\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\n@HabilitarCdiAndMockito\n@AdditionalClasses({ MeuProdutor.class }) // anotação do CDI Unit\npublic class MinhaClasseTeste {\n\n    @Inject\n    private MinhaClasse instancia;\n    \n    @Produces\n    @ProducesAlternative\n    @Mock\n    private MeuRecursoExterno recurso;\n\n    @Test\n    public void teste() {\n        // ...\n    }\n}\n```\n\n##### EJBs\n\nA anotação `@EJB` não é automaticamente processada na execução dos testes, uma vez que não há um contêiner de EJBs ativo. Para que a injeção de dependências funcione nesse caso, basta trocar a anotação por `@Inject`, que produz o mesmo efeito.\n\nOutra opção é a solução fornecida pelo _CDI Unit_, através da anotação `@SupportEjb`: [CDI Unit - EJB Support](http://jglue.org/cdi-unit-user-guide/#ejb).\n\n#### TEST Unit DBUnit\n\n##### Dependência\n\n```xml\n\u003cdependency\u003e\n    \u003cgroupId\u003ebr.jus.tst\u003c/groupId\u003e\n    \u003cartifactId\u003etest-unit-dbunit\u003c/artifactId\u003e\n    \u003cversion\u003e[1.0.0,)\u003c/version\u003e\n    \u003cscope\u003etest\u003c/scope\u003e\n\u003c/dependency\u003e\n```\n\n##### Uso\n\nPara utilizar essa extensão, é necessário ter um arquivo `testunit.properties` em seu _classpath_ (normalmente em `src/test/resources`). O conteúdo desse arquivo deve ter as propriedades abaixo:\n\n```\n# Valores obrigatórios:\n\n# Nome da classe de driver SQL a ser utilizada para abrir conexões JDBC\njdbc.driverClass=\n# URL do banco de dados\njdbc.url=\n# Usuário de banco de dados\njdbc.user=\n# Senha do usuário de banco de dados\njdbc.password=\n\n# Valores opcionais:\n\n# Diretório no classpath onde serão buscados os arquivos de dataset\ndbunit.datasets.dir=\n# Diretório no classpath onde serão buscados os arquivos de script\ndbunit.scripts.dir=\n# Nome da classe de DataType factory - ver http://dbunit.sourceforge.net/properties.html#DataType_factory\ndbunit.dataTypeFactoryClass=\n# Operação a ser executada antes de cada teste que utilize DataSets\ndbunit.beforeTests.operation=\n# Operação a ser executada após cada teste que utilize DataSets\ndbunit.afterTests.operation=\n```\n\nNotar que as propriedades `dbunit.beforeTests.operation` e `dbunit.afterTests.operation` devem ter como valor o nome de uma das constantes disponíveis em [DatabaseOperation](http://dbunit.sourceforge.net/apidocs/org/dbunit/operation/DatabaseOperation.html). Por padrão, elas possuem os valores `CLEAN_INSERT` e `DELETE_ALL`, respectivamente.\n\nAlém da anotação `@HabilitarDbUnit`, existe um outro conjunto de anotações que podem ser úteis para a execução do teste:\n\n* `@RodarScriptAntes`: define um ou mais arquivos de script a serem executados antes de um método de teste ou antes de todos os métodos de teste de uma classe. Por padrão, os arquivos são procurados dentro de um diretório `scripts` no _classpath_. Para maiores detalhes, ver Javadoc da anotação.\n* `@RodarScriptDepois`: define um ou mais arquivos de script a serem executados após um método de teste ou após todos os métodos de teste de uma classe. Por padrão, os arquivos são procurados dentro de um diretório `scripts` no _classpath_. Para maiores detalhes, ver Javadoc da anotação.\n* `@UsarDataSet`: define um arquivo de _dataset_ do DBUnit a ser utilizado pelo teste. O banco é carregado com os dados definidos no arquivo antes da execução do teste (operação _CLEAN-INSERT_). Por padrão, o arquivo é procurado dentro de um diretório `datasets` no _classpath_. OBS.: Não é possível utilizar simultaneamente esta anotação em um método de teste e em sua classe. Nesse caso, somente será considerada a anotação da classe.\n\n```java\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\n@HabilitarDbUnit(nomeSchema = \"TT\")\n@RodarScriptAntes(\"criar-schema.sql\")\n@RodarScriptDepois(\"drop-schema.sql\")\npublic class MinhaClasseTeste {\n\n    @Inject\n    private MinhaClasse instancia;\n\n    @Test\n    @UsarDataSet(\"meus-dados.xml\")\n    public void teste() {\n        // ...\n    }\n}\n```\n\n##### Múltiplos DataSets\n\nÉ possível utilizar diversos arquivos de dados do DBUnit nos testes, como no exemplo abaixo:\n\n```java\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\n@HabilitarDbUnit(nomeSchema = \"TT\")\n@RodarScriptAntes(\"criar-schema.sql\")\n@RodarScriptDepois(\"drop-schema.sql\")\n@UsarDataSet(\"meu-dataset-geral.xml\")\npublic class MinhaClasseTeste {\n\n    @Inject\n    private MinhaClasse instancia;\n\n    @Test\n    @UsarDataSets({\n    \t@UsarDataSets(value = \"meu-dataset-1.xml\", operacaoPreTestes = Operacao.INSERT, operacaoPosTestes = Operacao.NONE),\n    \t@UsarDataSets(value = \"meu-dataset-2.xml\")\n    })\n    public void testeMultiplosDatasets() {\n        // ...\n    }\n}\n```\n\nNote que são utilizados no total 3 arquivos no teste `testeMultiplosDatasets`: `meu-dataset-geral.xml`, `meu-dataset-1.xml` e `meu-dataset-2.xml`. O comportamento é que os arquivos sejam processados na ordem: arquivos definidos a nível de classe (sequencialmente) -\u003e arquivos definidos a nível de método (sequencialmente).\n\n**Importante:** A anotação `@UsarDataSets` permite que sejam customizadas as operações a serem executadas antes e após cada teste. Caso isso não seja feito, o comportamento padrão define que sejam usadas as operações configuradas no arquivo `testunit.properties` (ver acima em _Uso_). Isso pode não ser o desejado, visto que, por exemplo, caso a operação pré-testes configurada seja `CLEAN_INSERT`, isso fará com que todas as tabelas referenciadas em cada arquivo de dados sejam apagadas assim que o arquivo for processado. No exemplo acima, o fluxo de execução foi definido da seguinte forma:\n\n1. `CLEAN_INSERT \"meu-dataset-geral.xml\"` (_default_)\n2. `INSERT \"meu-dataset-1.xml\"` (customizado)\n3. `CLEAN_INSERT \"meu-dataset-2.xml\"`(_default_)\n4. `Execução do teste`\n4. `DELETE_ALL \"meu-dataset-2.xml\"` (_default_)\n5. `DELETE_ALL \"meu-dataset-geral.xml\"` (_default_)\n\n##### Gerando DTD\n\nO módulo também fornece um recurso que auxilia na geração de arquivos [DTD](http://www.w3schools.com/xml/xml_dtd.asp) do _schema_ de banco de dados.\n\nPara utilizá-lo, crie uma classe de teste em seu projeto semelhante a essa:\n\n```\n@RunWith(TestUnitRunner.class)\n@HabilitarDbUnit\npublic class GeradorDbUnitDtd {\n\n    @Test\n    // @Ignore\n    @GerarDtd(\"src/test/resources/datasets/pl.dtd\")\n    public void gerarDtd() {\n    \t/* \n    \t   Pode ser necessário incluir aqui um assertTrue(true) ou deixar um @Ignore no teste para evitar falsos índices de quantidade de testes de seu \n    \t   projeto ou problemas com ferramentas de análise de código, como Sonar.\n    \t*/\n    }\n}\n```\n\nLembre-se que o _schema_ de banco de dados precisa estar criado para que possa ser exportado pela ferramenta. Como opções, você pode usar a anotação `@RodarScriptAntes` para executar um arquivo de script que crie o _schema_ ou também tirar proveito da extensão _TEST Unit JPA_ - em conjunto com configurações do próprio JPA, é possível delegar para sua implementação de JPA (ex.: Hibernate) a criação do _schema_. Para maiores informações sobre uso do _TEST Unit JPA_, veja abaixo.\n\n##### Nota sobre transações\n\nAo realizar operações de inserção, deleção e atualização em seus testes com JPA/Hibernate, pode ser que você observe-as não sendo efetivadas no banco de dados caso seu código de produção dependa de um gerenciador de transações ativo (o que não existe durante a execução dos testes). Assim, você deverá iniciar e finalizar suas transações manualmente, como no exemplo abaixo, que utiliza CDI (ver _TEST Unit JPA_):\n\n```java\n    @Inject\n    private EntityManager entityManager;\n\n    @Test\n    public void meuTeste() {\n    \t// ...\n    \t\n\t\ttry {\n\t\t\tentityManager.getTransaction().begin();\n\t\t\tmeuServico.inserir(objeto); // o serviço utiliza o mesmo entityManager internamente\n\t\t\tentityManager.getTransaction().commit();\n\t\t} catch (PersistenceException exception) {\n\t\t\tentityManager.getTransaction().rollback();\n\t\t}\n\t\t\n\t\t// ...\n\t}\n```\n\n##### Acessando as conexões diretamente\n\nCaso seja necessário ter acesso direto às conexões utilizadas pelo _TEST Unit DBUnit_, você pode fazer conforme o exemplo abaixo:\n\n```java\n\ttry {\n\t    Configuracao configuracao = Configuracao.getInstance().carregar();\n\t    JdbcConnectionSupplier connectionSupplier = new JdbcConnectionSupplier(configuracao.getSubPropriedades(\"jdbc\"));\n\t    Connection connection = connectionSupplier.get(); // uma conexão com o banco utilizado pelo TEST Unit DBUnit\n\t} catch (TestUnitException exception) {\n\t    // TODO Tratar exception\n\t}\n```\n\n#### TEST Unit JPA\n\n##### Dependência\n\n```xml\n\u003cdependency\u003e\n    \u003cgroupId\u003ebr.jus.tst\u003c/groupId\u003e\n    \u003cartifactId\u003etest-unit-jpa\u003c/artifactId\u003e\n    \u003cversion\u003e[1.0.0,)\u003c/version\u003e\n    \u003cscope\u003etest\u003c/scope\u003e\n\u003c/dependency\u003e\n```\n\n##### Uso\n\nUtilize a anotação `@HabilitarJpa` em seus testes:\n\n```java\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\n@HabilitarJpa(nomeUnidadePersistencia = \"meuPU\")\npublic class MinhaClasseTeste {\n\n    private EntityManager em;\n    \n    @Before\n    public void setUp() {\n    \t// a instância de entityManager criada é singleton\n        em = EntityManagerCacheProducer.getUniqueEntityManager().get();\n    }\n\n    @Test\n    public void teste() {\n        // ...\n    }\n}\n```\n\nOBS.: Não é necessário fechar a instância de `EntityManager` fornecida, pois isso será feito internamente após a execução dos seus testes.\n\n##### Integração com outros módulos\n\nÉ possível usar essa extensão em conjunto com a _TEST Unit CDI_, de modo que seus testes ficarão com uma estrutura semelhante à essa:\n\n```java\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\n@HabilitarCdiAndMockito\n@AdditionalClasses({ EntityManagerFactoryProducerExtension.class }) // extensão que habilita os produtores do JPA\n@HabilitarJpa(nomeUnidadePersistencia = \"meuPU\", geradorSchema = GeradorSchemaCdi.class)\npublic class MinhaClasseTeste {\n\n    // @Inject\n    // private EntityManager em;\n    @Inject\n    private MinhaClasseQueUsaEntityManager instancia;\n\n    @Test\n    public void teste() {\n        // ...\n    }\n}\n```\n\nNota sobre `GeradorSchemaCdi`: esta classe tem a função de utilizar a instância de `EntityManager` fornecida pelo contêiner do CDI para gerar o _schema_ de banco de dados. Notar que, para isso, é necessário habilitar a função _ hbm2ddl_ do seu framework ORM (Hibernate).\n\nCaso você queira usar essa extensão em conjunto com a _TEST Unit DBUnit_, é possível gerar o _schema_ de banco antes de cada teste:\n\n```java\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\n@HabilitarCdiAndMockito\n@AdditionalClasses({ EntityManagerFactoryProducerExtension.class })\n@HabilitarDbUnit\n@HabilitarJpa(nomeUnidadePersistencia = \"meuPU\", geradorSchema = GeradorSchemaCdi.class)\npublic class MinhaClasseTeste {\n\n    @Inject\n    private MinhaClasseQueUsaEntityManager instancia;\n\n    @Test\n    @UsarDataSet(\"meu-dataset.xml\")\n    public void teste() {\n        // ...\n    }\n}\n```\n\nBasta definir a propriedade `hibernate.hbm2ddl.auto` no seu arquivo `persistence.xml` utilizado pelos testes com o valor `create`:\n\n```xml\n\u003cpersistence-unit name=\"meuPU\"\u003e\n\n\t...\n\t\n    \u003cproperties\u003e\n    \t...\n    \t\u003cproperty name=\"hibernate.hbm2ddl.auto\" value=\"create\" /\u003e\n       ...\n    \u003c/properties\u003e\n\u003c/persistence-unit\u003e\n```\n\nOBS.: O valor `create-drop` não é suportado dessa forma pois o JPA irá derrubar o _schema_ assim que o último `EntityManager` for fechado, ocasionando erros na execução do _TEST Unit DBUnit_, que irá tentar limpar o banco de dados em seguida.\n\nPara evitar duplicação de configuração de banco de dados (arquivos `persistence.xml` e `testunit.properties`), é possível utilizar apenas o último, deixando seu `persistence.xml` de testes com uma configuração mínima, conforme exemplo abaixo:\n\n```xml\n\u003cpersistence-unit name=\"meuPU\" transaction-type=\"RESOURCE_LOCAL\"\u003e\n\t\u003cprovider\u003eorg.hibernate.jpa.HibernatePersistenceProvider\u003c/provider\u003e\n\t\n\t\u003cclass\u003ebr.jus.tst.modelo.MinhaEntidade\u003c/class\u003e\n\u003c/persistence-unit\u003e\n```\n\nE no `testunit.properties`, configurações adicionais a serem repassadas para seu framework ORM podem ser definidas através do prefixo `jpa.orm`:\n\n```\n#jdbc.driverClass=\n#jdbc.url=\n#jdbc.user=\n#jdbc.password=\n\njpa.orm.hibernate.dialect=org.hibernate.dialect.H2Dialect\njpa.orm.hibernate.default_schema=FOO\njpa.orm.hibernate.show_sql=true\njpa.orm.hibernate.format_sql=true\njpa.orm.hibernate.hbm2ddl.auto=create-drop\n```\n\nNotar quer as propriedades de conexão JDBC definidas pelo _TEST Unit DBUnit_ (prefixo `jdbc`), caso presentes neste arquivo, também serão repassadas para o framework ORM com as devidas alterações de nome/chave.\n\n##### Múltiplas unidades de persistência no mesmo teste\n\nCaso seu teste utilize mais de uma unidade de persistência, o corpo da anotação `@HabilitarJpa` ficará um pouco diferente, conforme o exemplo abaixo:\n\n```java\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\n@HabilitarJpa(unidadesPersistencia = {\n\t\t@UnidadePersistencia(nome = \"testePU\", qualifierClass = TestePU.class),\n        @UnidadePersistencia(nome = \"teste2PU\", qualifierClass = Teste2PU.class) }, geradorSchema = GeradorSchemaCdi.class)\n@HabilitarCdiAndMockito // esse recurso pode ser utilizado com o CDI\n@AdditionalClasses({ EntityManagerFactoryProducerExtension.class })\npublic class MinhaClasseTeste {\n\n    @Inject\n    @TestePU\n    private EntityManager entityManager1;\n\n    @Inject\n    @Teste2PU\n    private EntityManager entityManager2;\n    \n    @Inject\n    private MinhaClasseQueUsaEntityManager instancia;\n\n    @Test\n    public void teste() {\n        // ...\n    }\n}\n```\n\n#### TEST Unit Mockito\n\n##### Dependência\n\n```xml\n\u003cdependency\u003e\n    \u003cgroupId\u003ebr.jus.tst\u003c/groupId\u003e\n    \u003cartifactId\u003etest-unit-mockito\u003c/artifactId\u003e\n    \u003cversion\u003e[1.0.0,)\u003c/version\u003e\n    \u003cscope\u003etest\u003c/scope\u003e\n\u003c/dependency\u003e\n```\n\n##### Uso\n\n```java\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\n@HabilitarMockito\npublic class MinhaClasseTeste {\n\n    @Mock\n    private MinhaClasse instancia;\n\n    @Test\n    public void teste() {\n        // ...\n    }\n}\n```\n\n#### TEST Unit JAX-RS\n\n##### Dependência\n\n```xml\n\u003cdependency\u003e\n    \u003cgroupId\u003ebr.jus.tst\u003c/groupId\u003e\n    \u003cartifactId\u003etest-unit-jaxrs\u003c/artifactId\u003e\n    \u003cversion\u003e[1.0.0,)\u003c/version\u003e\n    \u003cscope\u003etest\u003c/scope\u003e\n\u003c/dependency\u003e\n```\n\n##### Uso\n\nEsta extensão funciona em conjunto com a _TEST Unit CDI_. Dessa forma, basta incluir alguns itens na anotação `@AdditionalClasses`, além de injetar a instância de `JaxRsEngine`, que fornece acesso a todas as funcionalidades da extensão.\n\nUtilizando RestEasy:\n\n```java\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\n@HabilitarCdiAndMockito\n@AdditionalClasses({ ResteasyCdiExtension.class, ResteasyEngine.class })\npublic class MinhaClasseTeste {\n\n    @Inject\n    @Resteasy\n    private JaxRsEngine jaxRsEngine;\n\n    @Test\n    public void teste() {\n        // jaxRsEngine. ...\n    }\n}\n```\n\n##### Integração com Jackson\n\nComo atualmente o Jackson pode ser encontrado sob dois _groupId_s e pacotes diferentes - `org.codehaus` e `com.fasterxml` - você precisa definir manualmente qual versão deve ser utilizada, caso use esse recurso. Isso pode ser feito através das implementações da interface `JsonToObjectConverter.java`:\n\n```java\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\n@HabilitarCdiAndMockito\n@AdditionalClasses({ ResteasyCdiExtension.class, ResteasyEngine.class })\npublic class MinhaClasseTeste {\n\n    @Inject\n    @Resteasy\n    private JaxRsEngine jaxRsEngine;\n    \n    @Inject\n    private ObjectMapper objectMapper;\n\n    @Test\n    public void teste() {\n        MeuObjeto meuObjeto = jaxRsEngine.get(...).executar().getObjetoRespostaUsando(stream -\u003e objectMapper.readValue(stream, MeuObjeto.class));\n        ...\n    }\n}\n```\n\n#### Testes parametrizados\n\nO TEST Unit também oferece suporte a testes parametrizados. Para isso, sua classe de teste deve utilizar algumas anotações diferentes:\n\n```java\n@RunWith(Parameterized.class)\n@UseParametersRunnerFactory(TestUnitParameterizedRunnerFactory.class)\npublic class MeuTesteParametrizado {\n\n    @Parameters\n    public static Collection\u003cObject[]\u003e parametros() {\n        return Arrays.asList(new Object[] { 1, \"1\" }, new Object[] { 2, \"2\" });\n    }\n\n    @Parameter(0)\n    public int numero;\n    @Parameter(1)\n    public String numeroString;\n\n    @Test\n    public void teste() {\n        assertThat(String.valueOf(numero), is(equalTo(numeroString)));\n    }\n}\n```\n\nNotar que o _runner_ definido em `@RunWith` deve ser o `Parameterized.class`, ao invés de `TestUnitRunner.class`. A outra anotação, `@UseParametersRunnerFactory`, é fornecida pelo próprio JUnit e é utilizada aqui para conectar o _runner_ de testes parametrizados com o _runner_ do TEST Unit.\n\nOutras anotações das extensões podem ser utilizadas normalmente:\n\n```java\n@RunWith(Parameterized.class)\n@UseParametersRunnerFactory(TestUnitParameterizedRunnerFactory.class)\n@HabilitarCdiAndMockito\n@AdditionalPackages({ TestEntityManagerProducer.class })\n@HabilitarJpa(nomeUnidadePersistencia = \"meuPU\")\npublic class MeuTesteParametrizado {\n\n    ...\n\n    @Test\n    public void teste() {\n        ...\n    }\n}\n```\n\n#### Criando novas extensões\n\nCaso seja necessário adicionar uma nova extensão ao TEST Unit, basta seguir os passos abaixo:\n\n1. Crie uma anotação para habilitar a extensão nas classes de teste:\n\n```java\npackage br.jus.tst.minhaextensao;\n\nimport static java.lang.annotation.ElementType.TYPE;\nimport static java.lang.annotation.RetentionPolicy.RUNTIME;\n\n@Target({ TYPE })\n@Retention(RUNTIME)\n@Inherited\n@Documented\npublic @interface HabilitarMinhaExtensao {\n\n}\n```\n\n2. Crie a classe que define a lógica da extensão:\n\n```java\npackage br.jus.tst.minhaextensao;\n\nimport org.junit.runner.notification.RunNotifier;\nimport org.junit.runners.model.*;\n\nimport br.jus.tst.tstunit.*;\n\npublic class MinhaExtensao extends AbstractExtensao\u003cHabilitarMinhaExtensao\u003e {\n\n    @Override\n    public void inicializar(Configuracao configuracao, RunNotifier notifier) throws TestUnitException {\n        // TODO Gerado automaticamente\n    }\n\n    @Override\n    public Statement criarStatement(Statement defaultStatement, FrameworkMethod method) throws TestUnitException {\n        // TODO Gerado automaticamente\n        return null;\n    }\n}\n```\n\nDê uma olhada na API da classe `AbstractExtensao` e da interface `Extensao` para verificar se existe algum método que você possa ter interesse em sobrescrever. Também pode ser útil verificar o código das classes das extensões já existentes, como `CdiExtensao` e `DbUnitExtensao`.\n\n3. Agora a nova extensão já pode ser habilitada nos testes:\n\n```\npackage br.jus.tst.teste;\n\n@RunWith(TestUnitRunner.class)\n@HabilitarMinhaExtensao\npublic class MinhaClasseTeste {\n\n    @Test\n    public void teste() {\n        // ...\n    }\n}\n```\n\n#### Problemas conhecidos\n\n##### Javassist\n\nCaso ocorra a situação de uma ou mais extensões não serem carregadas em seus testes, verifique se o _POM_ de seu projeto possui múltiplas dependências do _Javassist_ com _groupId_ distintos (ex.: `org.javassist` e `javassist`). Nesse caso, é necessário excluir a versão mais antiga do seu projeto, como no exemplo abaixo:\n\n```\n\u003cdependency\u003e\n    \u003cgroupId\u003e...\u003c/groupId\u003e\n    \u003cartifactId\u003e...\u003c/artifactId\u003e\n    \u003cexclusions\u003e\n        \u003cexclusion\u003e\n            \u003cgroupId\u003ejavassist\u003c/groupId\u003e\n            \u003cartifactId\u003ejavassist\u003c/artifactId\u003e\n        \u003c/exclusion\u003e\n    \u003c/exclusions\u003e\n\u003c/dependency\u003e\n```\n\nEsse problema é facilmente identificado elevando-se o nível de log geral ou apenas do pacote `br.jus.tst.tstunit` para `DEBUG` e analisando-se as mensagens impressas no console.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftst-labs%2Ftest-unit","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftst-labs%2Ftest-unit","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftst-labs%2Ftest-unit/lists"}