PROBAT v6 20220708 - 215928

You are using an UNLICENSED copy of Scroll PDF Exporter for Confluence.
Do you find Scroll PDF Exporter useful? Consider purchasing it today: https://www.k15t.com/software/scroll-pdf-exporter
TOTVSTEC
PROBAT
Exported on 07/08/2022

TOTVSTEC – PROBAT
You are using an UNLICENSED copy of Scroll PDF Exporter for Confluence. Do you find Scroll PDF Exporter useful? Consider purchasing it today: https://www.k15t.com/software/scroll-pdf-exporter
Table of Contents
1 Motor de Testes tlppCore .................................................................................10
2 Notas:.................................................................................................................11
3 1 - A História ......................................................................................................12
4 2 - Obtendo o PROBAT ......................................................................................13
4.1 1 - Download .......................................................................................................................... 13
4.2 2 - Include ............................................................................................................................... 13
4.3 3 - Patch .................................................................................................................................. 14
4.4 a - Verificando a instalação.................................................................................................... 14
5 3 - Configurando................................................................................................16
5.1 a - Arquitetura de diretórios do projeto................................................................................ 16
5.1.1 Fontes Oficiais Projeto >> /src/ ........................................................................................................................... 16
5.1.2 Testes >> /test/..................................................................................................................................................... 17
5.1.2.1 Módulos / Funcionalidades ................................................................................................................................. 17
5.2 b - Encontrando fontes oficiais ............................................................................................. 18
5.2.1 Hierarquia de diretórios ...................................................................................................................................... 18
5.2.2 Annotation............................................................................................................................................................ 18
5.2.3 Tabela SQLite ....................................................................................................................................................... 19
5.3 c - INI ....................................................................................................................................... 19
5.3.1 Exemplo: appserver.ini ........................................................................................................................................ 19
5.3.2 Descrição das chaves ........................................................................................................................................... 20
5.3.2.1 GENERAL............................................................................................................................................................... 20
5.3.2.2 SOURCE ................................................................................................................................................................ 20
5.3.2.3 TESTS.................................................................................................................................................................... 21
5.3.2.4 CODE COVERAGE .................................................................................................................................................. 21
5.3.2.5 EXPORT ................................................................................................................................................................. 22
5.3.2.6 VALIDATION .......................................................................................................................................................... 23
6 4 - Primeiros Passos ..........................................................................................24

6.1 1 - Criando código-fonte teste............................................................................................... 24
6.2 2 - Executando Testes ............................................................................................................ 24
7 5 - Construindo Testes ......................................................................................26
– 2
TOTVSTEC – PROBAT
7.1 a - Teste simples com função ................................................................................................ 26

7.2 b - Teste simples com classe ................................................................................................. 27

7.3 c - Teste completo com classe............................................................................................... 28
7.3.1 Importante ........................................................................................................................................................... 30
7.4 d - Asserts ............................................................................................................................... 30
7.4.1 assertEquals ......................................................................................................................................................... 31
7.4.1.1 Sintaxe .................................................................................................................................................................. 31
7.4.1.2 Parâmetros........................................................................................................................................................... 31
7.4.1.3 Retorno ................................................................................................................................................................. 32
7.4.1.4 Observações ......................................................................................................................................................... 32
7.4.1.5 Exemplos .............................................................................................................................................................. 32
7.4.1.6 Abrangência ......................................................................................................................................................... 32
7.4.2 assertNotEquals ................................................................................................................................................... 32
7.4.2.1 Sintaxe .................................................................................................................................................................. 32
7.4.2.2 Parâmetros........................................................................................................................................................... 33
7.4.2.3 Retorno ................................................................................................................................................................. 33
7.4.2.4 Observações ......................................................................................................................................................... 33
7.4.2.5 Exemplos .............................................................................................................................................................. 33
7.4.2.6 Abrangência ......................................................................................................................................................... 34
7.4.3 assertOK ............................................................................................................................................................... 34
7.4.3.1 Sintaxe .................................................................................................................................................................. 34
7.4.3.2 Parâmetros........................................................................................................................................................... 34
7.4.3.3 Retorno ................................................................................................................................................................. 34
7.4.3.4 Observações ......................................................................................................................................................... 35
7.4.3.5 Exemplos .............................................................................................................................................................. 35
7.4.3.6 Abrangência ......................................................................................................................................................... 35
7.4.4 assertError............................................................................................................................................................ 35
7.4.4.1 Sintaxe .................................................................................................................................................................. 35
7.4.4.2 Parâmetros........................................................................................................................................................... 36
7.4.4.3 Retorno ................................................................................................................................................................. 36
7.4.4.4 Observações ......................................................................................................................................................... 36
7.4.4.5 Exemplos .............................................................................................................................................................. 36
7.4.4.6 Abrangência ......................................................................................................................................................... 37
7.4.5 assertWarning ...................................................................................................................................................... 37
7.4.5.1 Sintaxe .................................................................................................................................................................. 37
– 3
TOTVSTEC – PROBAT
7.4.5.2 Parâmetros........................................................................................................................................................... 37
7.4.5.3 Retorno ................................................................................................................................................................. 37

7.4.5.4 Observações ......................................................................................................................................................... 37
7.4.5.5 Exemplos .............................................................................................................................................................. 38
7.4.5.6 Abrangência ......................................................................................................................................................... 38
7.4.6 assertTrue............................................................................................................................................................. 38
7.4.6.1 Sintaxe .................................................................................................................................................................. 38
7.4.6.2 Parâmetros........................................................................................................................................................... 38
7.4.6.3 Retorno ................................................................................................................................................................. 39
7.4.6.4 Observações ......................................................................................................................................................... 39
7.4.6.5 Exemplos .............................................................................................................................................................. 39
7.4.6.6 Abrangência ......................................................................................................................................................... 39
7.4.7 assertFalse............................................................................................................................................................ 39
7.4.7.1 Sintaxe .................................................................................................................................................................. 39
7.4.7.2 Parâmetros........................................................................................................................................................... 40
7.4.7.3 Retorno ................................................................................................................................................................. 40
7.4.7.4 Observações ......................................................................................................................................................... 40
7.4.7.5 Exemplos .............................................................................................................................................................. 40
7.4.7.6 Abrangência ......................................................................................................................................................... 41
7.4.8 assertGreater........................................................................................................................................................ 41
7.4.8.1 Sintaxe .................................................................................................................................................................. 41
7.4.8.2 Parâmetros........................................................................................................................................................... 41
7.4.8.3 Retorno ................................................................................................................................................................. 41
7.4.8.4 Observações ......................................................................................................................................................... 42
7.4.8.5 Exemplos .............................................................................................................................................................. 42
7.4.8.6 Abrangência ......................................................................................................................................................... 42
7.4.9 assertGreaterOrEqual .......................................................................................................................................... 42
7.4.9.1 Sintaxe .................................................................................................................................................................. 42
7.4.9.2 Parâmetros........................................................................................................................................................... 43
7.4.9.3 Retorno ................................................................................................................................................................. 43
7.4.9.4 Observações ......................................................................................................................................................... 43
7.4.9.5 Exemplos .............................................................................................................................................................. 43
7.4.9.6 Abrangência ......................................................................................................................................................... 44
7.4.10 assertLess ............................................................................................................................................................. 44
7.4.10.1 Sintaxe .................................................................................................................................................................. 44
– 4
TOTVSTEC – PROBAT
7.4.10.2 Parâmetros........................................................................................................................................................... 44
7.4.10.3 Retorno ................................................................................................................................................................. 44

7.4.10.4 Observações ......................................................................................................................................................... 44
7.4.10.5 Exemplos .............................................................................................................................................................. 45
7.4.10.6 Abrangência ......................................................................................................................................................... 45
7.4.11 assertLessOrEqual ............................................................................................................................................... 45
7.4.11.1 Sintaxe .................................................................................................................................................................. 45
7.4.11.2 Parâmetros........................................................................................................................................................... 46
7.4.11.3 Retorno ................................................................................................................................................................. 46
7.4.11.4 Observações ......................................................................................................................................................... 46
7.4.11.5 Exemplos .............................................................................................................................................................. 46
7.4.11.6 Abrangência ......................................................................................................................................................... 47
7.4.12 assertIsRegExFull ................................................................................................................................................. 47
7.4.12.1 Sintaxe .................................................................................................................................................................. 47
7.4.12.2 Parâmetros........................................................................................................................................................... 47
7.4.12.3 Retorno ................................................................................................................................................................. 47
7.4.12.4 Observações ......................................................................................................................................................... 48
7.4.12.5 Exemplos .............................................................................................................................................................. 48
7.4.12.6 Abrangência ......................................................................................................................................................... 48
7.4.13 assertIsRegExPartial ............................................................................................................................................ 48
7.4.13.1 Sintaxe .................................................................................................................................................................. 48
7.4.13.2 Parâmetros........................................................................................................................................................... 49
7.4.13.3 Retorno ................................................................................................................................................................. 49
7.4.13.4 Observações ......................................................................................................................................................... 49
7.4.13.5 Exemplos .............................................................................................................................................................. 49
7.4.13.6 Abrangência ......................................................................................................................................................... 50
7.4.14 assertIsContained ................................................................................................................................................ 50
7.4.14.1 Sintaxe .................................................................................................................................................................. 50
7.4.14.2 Parâmetros........................................................................................................................................................... 50
7.4.14.3 Retorno ................................................................................................................................................................. 50
7.4.14.4 Observações ......................................................................................................................................................... 50
7.4.14.5 Exemplos .............................................................................................................................................................. 51
7.4.14.6 Abrangência ......................................................................................................................................................... 51
7.4.15 assertJson ............................................................................................................................................................ 51
7.4.15.1 Sintaxe .................................................................................................................................................................. 51
– 5
TOTVSTEC – PROBAT
7.4.15.2 Parâmetros........................................................................................................................................................... 52
7.4.15.3 Retorno ................................................................................................................................................................. 52

7.4.15.4 Observações ......................................................................................................................................................... 52
7.4.15.5 Exemplos .............................................................................................................................................................. 52
7.4.15.6 Abrangência ......................................................................................................................................................... 53
7.4.16 assertNil................................................................................................................................................................ 53
7.4.16.1 Sintaxe .................................................................................................................................................................. 53
7.4.16.2 Parâmetros........................................................................................................................................................... 53
7.4.16.3 Retorno ................................................................................................................................................................. 54
7.4.16.4 Observações ......................................................................................................................................................... 54
7.4.16.5 Exemplos .............................................................................................................................................................. 54
7.4.16.6 Abrangência ......................................................................................................................................................... 54
7.4.17 assertNull.............................................................................................................................................................. 54
7.4.17.1 Sintaxe .................................................................................................................................................................. 55
7.4.17.2 Parâmetros........................................................................................................................................................... 55
7.4.17.3 Retorno ................................................................................................................................................................. 55
7.4.17.4 Observações ......................................................................................................................................................... 55
7.4.17.5 Exemplos .............................................................................................................................................................. 55
7.4.17.6 Abrangência ......................................................................................................................................................... 56
7.4.18 assertVector.......................................................................................................................................................... 56
7.4.18.1 Sintaxe .................................................................................................................................................................. 56
7.4.18.2 Parâmetros........................................................................................................................................................... 56
7.4.18.3 Retorno ................................................................................................................................................................. 57
7.4.18.4 Observações ......................................................................................................................................................... 57
7.4.18.5 Exemplos .............................................................................................................................................................. 57
7.4.18.6 Abrangência ......................................................................................................................................................... 57
7.5 e - Recursos Avançados ......................................................................................................... 57
7.5.1 e-1 - A Annotation TestFixture............................................................................................................................. 58
7.5.1.1 SUITE .................................................................................................................................................................... 58
7.5.1.2 OWNER.................................................................................................................................................................. 59
7.5.1.3 THREAD................................................................................................................................................................. 59
7.5.1.4 PRIORITY............................................................................................................................................................... 60
7.5.1.5 FOLDER ................................................................................................................................................................. 60
7.5.1.6 TEST ...................................................................................................................................................................... 61
7.5.1.7 DESCRIPTION ....................................................................................................................................................... 61
– 6
TOTVSTEC – PROBAT
7.5.1.8 TARGET ................................................................................................................................................................. 61

7.5.1.9 - RUNWITHALL | RWA............................................................................................................................................ 62

7.5.2 e-2 - Execução em thread .................................................................................................................................... 62
7.5.2.1 * Abre a Thread:.................................................................................................................................................... 63
7.5.2.2 * NÃO abre a Thread:............................................................................................................................................ 63
7.5.3 e-3 - Ordem e Prioridade...................................................................................................................................... 63
7.5.3.1 1 - Prioridade ........................................................................................................................................................ 63
7.5.3.2 2 - Thread.............................................................................................................................................................. 64
7.5.4 e-4 - Pulando Testes............................................................................................................................................. 65
7.5.4.1 Pulando Funções e Métodos inteiros - @Skip().................................................................................................. 65
7.5.4.2 Pulando asserts específicos - SKIPASSERT e SKIPTEST..................................................................................... 65
7.5.4.3 Utilizando filtros para o Skip ............................................................................................................................... 66
7.5.5 e-5 - Suites ............................................................................................................................................................ 69
7.5.5.1 Suítes customizadas ............................................................................................................................................ 70
7.5.5.2 Suítes Exclusivas .................................................................................................................................................. 70
7.5.6 e-6 - Cobertura de Código.................................................................................................................................... 71
7.5.6.1 Ativando a Cobertura........................................................................................................................................... 71
7.5.6.2 Recursos ............................................................................................................................................................... 72
7.5.6.3 Consolidação de Resultados ............................................................................................................................... 72
7.5.6.4 Exportação ........................................................................................................................................................... 74
7.5.6.5 Extensão VsCode .................................................................................................................................................. 75
7.5.6.6 Validação de Cobertura ....................................................................................................................................... 77
7.5.7 e-7 - Error Log ....................................................................................................................................................... 78
7.5.8 e-8 - Cross Validation ........................................................................................................................................... 79
8 6 - Executando Testes .......................................................................................82

8.1 a - Discovery - Encontrando os Testes no RPO ..................................................................... 82
8.1.1 Por Solicitação ..................................................................................................................................................... 82
8.1.1.1 1 - Main Function:................................................................................................................................................. 83
8.1.1.2 2 - Via api Rest: ..................................................................................................................................................... 83
8.1.2 Na Execução ......................................................................................................................................................... 83
8.2 b - Modos de execução........................................................................................................... 83
8.2.1 Todos testes ......................................................................................................................................................... 84
8.2.2 Testes de determinada namespace .................................................................................................................... 84
8.2.3 Testes de determinado código-fonte.................................................................................................................. 84
8.2.4 Testes com erro.................................................................................................................................................... 85
– 7
TOTVSTEC – PROBAT
8.2.5 Testes de Suítes específicas ................................................................................................................................ 85

8.3 c - Impondo a cobertura de código ....................................................................................... 86

8.3.1 Ligando Coverage ................................................................................................................................................ 86
8.3.2 Desligando Coverage ........................................................................................................................................... 86
8.3.2.1 Importante: .......................................................................................................................................................... 86
8.4 d - Identificador Customizado............................................................................................... 87
9 7 - Analisando Resultados ................................................................................88
9.1 a - Exportando Resultados .................................................................................................... 88
9.1.1 EXPORT_AFTER_RUN........................................................................................................................................... 88
9.1.2 EXPORT_FORMAT................................................................................................................................................. 88
9.1.3 EXPORT_FILE_NAME ............................................................................................................................................ 89
9.2 b - tlpp.probat.export().......................................................................................................... 90
9.3 c - Warning.............................................................................................................................. 91
9.4 d - SQLite ................................................................................................................................ 91
9.4.1 Testes.................................................................................................................................................................... 91
9.4.1.1 [PROBAT_TEST_EXECUTION] .............................................................................................................................. 92
9.4.1.2 [PROBAT_TEST_RESULTS] .................................................................................................................................. 92
9.4.1.3 [PROBAT_TEST_TESTS]....................................................................................................................................... 93
9.4.1.4 [PROBAT_TEST_ERRORS].................................................................................................................................... 94
9.4.1.5 [PROBAT_TEST_WARNING] ................................................................................................................................. 95
9.4.2 Cobertura de Códigos .......................................................................................................................................... 95
9.4.2.1 [PROBAT_CODECOVERAGE_TOTAL] ................................................................................................................... 95
9.4.2.2 [PROBAT_CODECOVERAGE_SOURCES] .............................................................................................................. 96
9.4.2.3 [PROBAT_CODECOVERAGE_LINES]..................................................................................................................... 96
10 8 - Como tudo acontece....................................................................................98

10.1 [A]............................................................................................................................................ 98
10.2 [B]............................................................................................................................................ 98
10.3 [C]............................................................................................................................................ 99
10.4 [D]............................................................................................................................................ 99
10.5 [E] .......................................................................................................................................... 100
10.6 [F] .......................................................................................................................................... 100
10.6.1 1 - Código fonte .................................................................................................................................................. 101
10.6.2 2 - VsCode ........................................................................................................................................................... 101
– 8
TOTVSTEC – PROBAT
10.6.3 3 - Linha de comando......................................................................................................................................... 101

10.7 [G].......................................................................................................................................... 101

11 9 - Exemplo no GitHub ....................................................................................102
– 9
TOTVSTEC – PROBAT
1 Motor de Testes tlppCore

O **PROBAT** é uma ferramenta do tlppCore para a execução de testes e apuração de resultados no processo de
desenvolvimento ágil, TDD (Test-driven development) e QA (Quality Assurance) de seu projeto.
O nome PROBAT vem do Latim e significa prova / testes, portanto, nenhum nome melhor representaria a
ferramenta de testes.
Suas principais características são:
• Facilidade de uso;
• Facilidade no desenvolvimento de testes;
• Flexibilidade na configuração;
• Armazena históricos dos testes em SQLite;
• Validação de cobertura de código;
• Exportação de resultados em formatos para uso em ferramentas de mercado.
Motor de Testes tlppCore – 10

2 Notas:
• Não possui recursos para testes de interface.
• Funciona somente a partir do binário (Build 7.00.170117A) Lobo-Guará.
Notas: – 11
TOTVSTEC – PROBAT
TOTVSTEC – PROBAT
3 1 - A História
Inicialmente ele foi concebido para atender os testes unitários do desenvolvimento dos componentes da
linguagem TL++, portanto ele era somente uma iniciativa tímida para atender uma necessidade específica.
A decisão de criar algo novo deu-se pelo fato de que as funcionalidades do TL++ devem funcionar corretamente
sem que haja dependências de nenhum outro produto.
Umas das premissas para essa iniciativa era utilizar em grande escala os recursos nativos da linguagem, não
somente em testes específicos como também na construção do motor de testes, pois ele é todo construído em TL+
+, são eles:
• Namespaces1
• Nomes longos2
• Reflection e Annotation3
• Tipagem de dados4
• RegEx5
• REST6
Com a concepção do tlppCore, RPO que é expedido juntamente com o appserver da TOTVS, contendo recursos
novos da linguagem e produtos nativos à tecnologia TOTVS, houve a necessidade de ampliar a abrangência do
Motor de Testes.
Logo vimos que o Motor precisava mais do que atender testes unitários, necessitava também de Testes Integrados,
Testes Sistêmicos, Testes Funcionais e Testes de Versões.
Além disso nosso cenário de ambiente de testes cresceu consideravelmente, tal como testar ambiente de
desenvolvimento, ambiente Master e o ambiente final chamado Stable, isso tudo para Windows, Linux utilizando
appserver Lobo-Guará e Harpia.
Resumidamente o motor deixou de ser um Motor de Testes Unitários para um MOTOR DE TESTES.
Com isso, a ferramenta que nasceu para ser um apoio ao nosso trabalho, se tornou um módulo extremamente
funcional e robusto, e acreditamos que pode ser útil para nossos clientes e parceiros assim como é para nós!
Seja bem vindo!
1 https://tdn.totvs.com/display/tec/Namespace
2 https://tdn.totvs.com/display/tec/Nomes+longos
3 https://tdn.totvs.com/display/tec/Reflection+e+Annotation
4 https://tdn.totvs.com/pages/viewpage.action?pageId=579304379
5 https://tdn.totvs.com/display/tec/RegEx
6 https://tdn.totvs.com/display/tec/REST
1 - A História – 12
TOTVSTEC – PROBAT
4 2 - Obtendo o PROBAT
Para utilizar o PROBAT, será necessário primeiro obter e instalar a ferramenta em seu ambiente.
Recomendamos fortemente que não seja instalado em seu ambiente de produção, sendo indicado separar um
ambiente para testes.
Veja os passos a seguir:
4.1 1 - Download
 tlppCore version 01.03.00

Para ambientes tlppCore com versão igual ou superior a 01.03.00, não será necessário seguir esse item
pois o PROBAT já será expedido em seu tlpp.rpo
Primeiro será necessário fazer download dos pacotes do produto para aplicar em seu ambiente.
Para isso, utilize a página de DOWNLOAD do tlppCore e busque os pacotes do PROBAT (Test Engine).
https://tdn.totvs.com/display/tec/Downloads
Você precisará de 2 (dois) arquivos, sendo:
• tlpp-probat.th
• probat_{versao_appserver}.ptm
4.2 2 - Include

Para ambientes tlppCore com versão igual ou superior a 01.03.00, você apenas precisa extrair as Includes
do tlppCore seguindo as instruções descritas em: Ambiente de compilação do TLPP7
Ao obter o arquivo tlpp-probat.th, copie-o para a mesma pasta de includes que você utilize em seu ambiente.
Caso queira utilizar uma pasta diferentes dos includes do Protheus, não pode esquecer de informar essa nova pasta
em seu VsCode.
Todos os seus fontes de testes deverão importar a include do PROBAT, como o exemplo abaixo:
#include "tlpp-probat.th"
2 - Obtendo o PROBAT – 13
TOTVSTEC – PROBAT
4.3 3 - Patch

Para ambientes tlppCore com versão igual ou superior a 01.03.00, esse passo é desnecessário
Haverá dois patchs para download, portanto no passo anterior obtenha o patch conforme a versão de seu
appserver, ou seja, Lobo-Guará ou Harpia.
• probat_LoboGuara.ptm
ou
• probat_Harpia.ptm
A aplicação do patch é simples e segue igualmente o processo de todo patch e podem ser realizado de duas
maneiras:
• VsCode
Siga as instruções conforme documentação da extensão oficial da TOTVS:
tds-vscode - Aplicando de pacotes de atualização (_patch)8
• Linha de comando
O appserver possui o recurso de se aplicar patch através de linha de comando, como o exemplo abaixo:
appserver.exe -compile -applypatch -files=D:\totvs\patch\probat_Harpia.ptm -env=a

dvplc -applyoldprogram
Para saber mais sobre o recurso de linha de comando, acesse sua documentação:
AppServer Command Line9
4.4 a - Verificando a instalação

Para verificar se o PROBAT está instalado e qual a sua versão, basta utilizar a seguinte instrução:
function sampleIsProbat()

local jModule

if ( tlpp.module( 'PROBAT', @jModule ) )
conout( 'Ferramenta: ' + jModule['module'] )
conout( 'Instalado?: ' + if( jModule['linked'], 'sim', 'não' ) )
conout( 'Versão....: ' + jModule['version'] )
8 https://github.com/totvs/tds-vscode/blob/HEAD/docs/apply-patch.md
TOTVSTEC – PROBAT
else
conout( ' >> Ferramenta não instalada <<' )

endif

return Nil
Saiba mais sobre esse recurso em:

Ambiente: verificando existência dos módulos10
TOTVSTEC – PROBAT
5 3 - Configurando
O PROBAT utiliza principalmente o INI do appserver para chavear configurações de suas funcionalidades através de
uma sessão própria, tal como abaixo:
[PROBAT]
Todas as chaves de configuração serão descritas nas páginas seguintes.
Porém, alguns pontos também podem ser configurados através de comandos que devem ser compilados em seu
projeto, saiba mais em:
• Cobertura de Código(see page 71)
• Suites(see page 69)
• Cross Validation(see page 79)
Continue aprendendo a configurar seu ambiente em:
• a - Arquitetura de diretórios do projeto(see page 16)

• b - Encontrando fontes oficiais(see page 18)
• c - INI(see page 19)
5.1 a - Arquitetura de diretórios do projeto

Aconselhamos a utilização de um "versionador" de código, tal como o GIT.
Após criar um projeto novo em seu GIT remoto, faça o clone para criar seu diretório principal do projeto, na qual
terão todos os arquivos fontes do seu projeto.
Caso não queria utilizar uma ferramenta de versionamento, apenas crie o diretório.
Exemplo:
C:\my_project
Agora que temos nosso diretório principal do projeto, vamos começar a criar a estrutura na qual iremos trabalhar.
Vamos agora a criação de mais 2 (dois) diretórios, importante citar que serão subdiretórios a partir do principal do
projeto, e eles serão base para distinguir dois tipos de fontes, são eles:
5.1.1 Fontes Oficiais Projeto >> /src/

Os fontes abaixo desse diretório contém o desenvolvimento de funções e classes com as funcionalidades, regras,
telas, api´s, etc.. que seu projeto necessita.
Esses fontes são os que estarão no RPO de produção de seu ambiente final.
3 - Configurando – 16
TOTVSTEC – PROBAT
Ficando então:
C:\my_project\src\
5.1.2 Testes >> /test/

Os fontes abaixo desse diretório contém as implementações com os testes unitários, funcionais, integrados das
funcionalidades desenvolvidas no diretório descrito acima.
Essas classes/funções não precisam ficar no RPO final de produção, na verdade, em boas práticas é bom que NÃO
sejam expedidos ao RPO de produção, pois seu uso só é essencial ao ambiente e RPO que serão executados os
testes.
Ficando então:
C:\my_project\test\
5.1.2.1 Módulos / Funcionalidades

Abaixo desses diretórios novos, todos os subdiretórios criados serão associados à funcionalidade a ser
desenvolvida e todo diretório novo em /src/ precisa ter seu correspondente criado na estrutura em /test/.
Embora não seja uma exigência técnica que ambos diretórios tenham o mesmo nome, utilizamos esse padrão por 2
(dois) bons motivos:
• Boas práticas de desenvolvimento;
• Facilidade de manutenção
Com essa organização de diretórios, facilitamos o entendimento e manutenção das funcionalidades principais ao
agrupar os fontes com as mesmas finalidades, como também, facilita a encontrar todos os fontes dos testes para
essa funcionalidade.
Exemplo:
Imagine que temos alguns fontes com manipulação de datas em nosso projeto, portanto, é importante agrupá-los
em um mesmo local, nesse caso poderemos utilizar o nome /date/.
Logo, todos os testes desenvolvidos para cobrir todas as funcionalidades de data colocaremos também em /date/.
Como temos duas estruturas de diretórios, uma para a implementação da funcionalidade e outra para os testes,
devemos então ter /date/ nos dois locais, ou seja, /src/ e /test/.
Em nosso exemplo acima, a estrutura final fica:
C:\my_project\src\date
C:\my_project\test\date
TOTVSTEC – PROBAT
5.2 b - Encontrando fontes oficiais

Para algumas funcionalidades é importante que o PROBAT tenha conhecimento sobre quais são os fontes oficiais
do seu projeto.
Hoje o PROBAT possui 2 modos de encontrar os fontes, sendo:
• Hierarquia de diretórios;
• Annotation.
5.2.1 Hierarquia de diretórios

Caso você tenha seguido a recomendação anterior em (Arquitetura de diretórios do projeto) e todos os seus fontes
oficiais estejam abaixo de /src/, recomendamos utilizar o modo [Hierarquia de diretórios], pois ele é o mais simples
e eficaz, uma vez que ele irá encontrar todos os arquivos-fontes que existem fisicamente abaixo do diretório raiz.
Para isso, em seu INI informe:
[PROBAT]
SOURCE_DISCOVERY_MODE=0
SOURCE_PATH=C:/my_project/src/
Sendo:
• {SOURCE_DISCOVERY_MODE=0} Informa que o PROBAT fará as buscas dos arquivos por hierarquia de
diretórios.
• {SOURCE_PATH=C:/my_project/src/} Diretório raiz onde possui todos os arquivos-fontes oficiais e
subdiretórios do projeto.
5.2.2 Annotation
Caso você tenha os fontes distribuídos de forma organizada diferente da descrita em [Hierarquia de diretórios] e o
processo de refatorar a localização dos arquivos seja muito custoso, então o PROBAT possui um modo de
encontrá-los através do uso de annotation.
Primeiro é preciso configurar o funcionamento para esse modo, sendo assim, informe conforme abaixo em sua INI:
[PROBAT]
Depois, em cada fonte oficial e em qualquer função ou classe presentes no fonte utilizar a annotation
[DiscoverySrc].
Exemplo:
TOTVSTEC – PROBAT
@DiscoverySrc(folder="/my_project/src/date")
user function myDate()
...
Através da propriedade [folder] você irá informar qual o diretório na qual esse fonte está localizado.
Portanto através da reflection o PROBAT irá buscar todos os fontes que utilizam [DiscoverySrc] e assumirá como
fontes oficiais do seu projeto.
Importante ressaltar que esse modo possui algumas limitações, vejamos:
• Só funcionará com fontes .tlpp, pois Annotation e Reflection é um recurso exclusivo do TL++.
• Logo, fontes em ADVPL não serão encontrados por esse modo;
• É preciso refatorar todos os seus fontes oficiais para a inserção do @DiscoverySrc().
• Seu projeto precisa ser recompilado para que o recurso funcione.
5.2.3 Tabela SQLite

Ao descobrir os arquivos fontes oficiais, o PROBAT irá gravar os dados na seguinte tabela do SQLite.
Nome Tabela: PROBAT_CONFIG_SOURCES
Campo Tipo Dado Descrição
CODE N Código do fonte oficial (uso interno)
FOLDER C Folder de localização do fonte
SOURCE C Nome do arquivo fonte
NAMESPACE C Namespace usada no fonte
5.3 c - INI
5.3.1 Exemplo: appserver.ini

[PROBAT]
DEVTLPP=0
SOURCE_PATH=C:/my_project/src/
SOURCE_SKIPPED_PATH=subfolder_1,subfolder_3
TESTS_DISCOVERY_MODE=0
TESTS_DISCOVERY_TIME_INTERVAL=3600
CROSS_VALIDATION=u_minha_funcao_cross
CODECOVERAGE=1
CODECOVERAGE_EXPORT_JSON=1
TOTVSTEC – PROBAT
CODECOVERAGE_PERCENT=80
CODECOVERAGE_EXPORT_TFS=1
CODECOVERAGE_FILTER_SRC=subfolder_2,subfolder_4
EXPORT_FILE_NAME=test_results
EXPORT_AFTER_RUN=1
EXPORT_FORMAT=JUnit
ISFREAK=palavra_bloqueada_1,palavra_bloqueada_2
ShutDown=0
5.3.2 Descrição das chaves

Para descrever as chaves, iremos juntar em grupos conforme suas finalidades, conforme abaixo:
5.3.2.1 GENERAL
Configurações genéricas.
DEVTLPP=0
ATENÇÃO
Essa chave deve sempre estar com o valor 0 (zero), pois 1 (um) é de uso exclusivo da equipe de desenvolvimento do
tlppCore e ativar essas particularidades pode causar comportamentos inesperados em seu projeto.
ShutDown=0
Determina se ao final da execução dos testes o appserver será finalizado automaticamente ou permanece no ar.
0 = Mantém no ar o appserver.
1 = Finaliza appserver
5.3.2.2 SOURCE
Configurações referentes aos arquivos fontes oficiais do projeto.
Informa o modo de encontrar os arquivos fontes oficiais de seu projeto.
• 0 = Hierarquia de diretórios
• 1 = Annotation.
Veja a documentação completa sobre esse recurso em:
Encontrando fontes oficiais(see page 18)
TOTVSTEC – PROBAT
SOURCE_PATH=d:\tlppCore\src
Indica qual o diretório onde se encontram os arquivos fontes oficiais quando informado 0 (zero) em
[SOURCE_DISCOVERY_MODE].
Veja a documentação completa sobre esse recurso em:
Encontrando fontes oficiais(see page 18)
SOURCE_SKIPPED_PATH=subfolder_1,subfolder_3
Indica qual subdiretórios serão ignorados na busca pelos fontes oficiais para registrar no SQLite quando informado
0 (zero) em [SOURCE_DISCOVERY_MODE].
Caso nada seja informado, nenhum subdiretório seja ignorado, e caso precise de mais de um subdiretório separe
por vírgula ",".
5.3.2.3 TESTS
Configurações referentes aos fontes de Testes do projeto.
Informa o modo de descoberta dos fontes de testes, sendo:
• 0 - Por Solicitação
• 1 - Na Execução
Para saber mais sobre esse recurso, visite:
Discovery - Encontrando os Testes no RPO(see page 82)
Indica o intervalo em segundos que o PROBAT faz buscas novamente dos fontes de testes compilados no RPO.
Para saber mais sobre esse recurso, visite:
Discovery - Encontrando os Testes no RPO(see page 82)
5.3.2.4 CODE COVERAGE

Configurações referentes à Cobertura de Código.
CODECOVERAGE=1
Indica que deseja ligar/desligar a cobertura de código na execução dos testes.
TOTVSTEC – PROBAT
• 0 = Desligado
• 1 = Ligado
Saiba mais em:
Cobertura de Código(see page 71)
Indica o percentual mínimo de cobertura aceito sobre os fontes oficiais.
Saiba mais em:
Indica que deseja exportar em formato JSON os resultados de cobertura de código.
Saiba mais em:
Indica que deseja exportar em formato COBERTURA (XML) os resultados de cobertura de código.
Saiba mais em:
CODECOVERAGE_FILTER_SRC=subfolder_2,subfolder_4
Indica quais subdiretórios do seu projeto serão considerados na validação no processo de cobertura de código.
Saiba mais em:
5.3.2.5 EXPORT
Configurações referentes à exportação dos resultados dos testes.
EXPORT_FILE_NAME=test_results
Informa o nome do arquivo de exportação dos resultados.
Saiba mais em:
Exportando Resultados(see page 88)
TOTVSTEC – PROBAT
EXPORT_AFTER_RUN=1
Indica se deseja que gere os resultados logo após a execução dos testes.
0 = Não gera arquivo.
1 = Gera arquivo com resultado, baseado em EXPORT_FILE_NAME e EXPORT_FORMAT.
Saiba mais em:
EXPORT_FORMAT=JUnit
Formato do arquivo com resultado dos testes.
Saiba mais em:
5.3.2.6 VALIDATION
Configurações referentes à validações adicionais.
CROSS_VALIDATION=u_minha_funcao_cross
Ativa o Cross Validation informando a função de usuário que retornará a lista de "alvos".
Veja mais detalhes sobre esse recurso em: e-8 - Cross Validation(see page 79)
Ao não informar nenhuma função para essa chave, essa validação é desativada.
ISFREAK=palavra_bloqueada_1,palavra_bloqueada_2
Determina uma lista de palavras que serão bloqueadas no uso das descrições dos testes, assim poder-se-á impedir
o uso de palavras inadequadas.
As palavras devem ser separada por vírgula "," quando houver mais de 1 (uma) palavra.
Ao não informar nenhuma palavra para essa chave, essa validação é desativada.
TOTVSTEC – PROBAT
6 4 - Primeiros Passos
6.1 1 - Criando código-fonte teste

Agora que seu ambiente está pronto, já podemos escrever o primeiro arquivo-fonte de teste.
Para esse exemplo, iremos construir um teste verificando se a função valtype() está retornando conforme esperado.
Notem que é extremamente simples:
@TestFixture()
user function sampeTestBasic()
local nVar := 0
local cValue := valtype( nVar )
tlpp.probat.assertEquals( cValue, 'N' )
return .T.
Elementos exclusivos do PROBAT

• #include "tlpp-probat.th11"
• @TestFixture()
• tlpp.probat.assertEquals()
Notas:
• A função sempre deve retornar .T., ao menos que você queira estruturar seu teste para que alguns casos
retorne .F., gerando erro automático ao final da execução.
• Para gerar resultado dos testes, é necessário executar ao menos 1 (uma) função de Assert() do acervo do
PROBAT.
• É possível escrever os testes com classes também, inclusive através de classe teremos mais recursos
disponíveis. O uso de função de testes é limitado porém mais simples.
Ao final, compile esse fonte no mesmo ambiente onde foi aplicado o patch.
6.2 2 - Executando Testes

Agora que temos ao menos um teste criado e compilado, podemos então solicitar a execução, sendo assim basta
executar a seguinte função:
tlpp.probat.run()
11 http://tlpp-probat.th
4 - Primeiros Passos – 24
TOTVSTEC – PROBAT
Essa função é do tipo Main Function, portanto pode ser chamada diretamente na execução pelo VsCode ou por
linha de comando do appserver.
Exemplo de Linha de comando:
appserver.exe -console -consolelog -run=tlpp.probat.run -env={NOME_AMBIENTE}
4 - Primeiros Passos – 25
TOTVSTEC – PROBAT
7 5 - Construindo Testes
Concentraremos nesse grupo todos as funcionalidades disponíveis para a construção de testes, portanto
aconselhamos ler todas as páginas.
Todos os exemplos usados nessa documentação terão como foco testar as funções já conhecidas aos
desenvolvedores ADVPL e TL++, são elas:
Função Link TDN
valType() https://tdn.totvs.com/display/tec/ValType
strTokArr2() https://tdn.totvs.com/display/tec/StrTokArr2
max() https://tdn.totvs.com/display/tec/Max
int() https://tdn.totvs.com/display/tec/Int
Para seguir com a implementação é preciso ter os seguintes conhecimentos prévios:

• Criação de Classes em AdvPL12 ** Exceto para o modo simples de teste.
• Reflection e Annotation13
7.1 a - Teste simples com função

O modo mais simples e menos verboso para escrever um teste é através de uma "function" ou "user function".
No exemplo abaixo iremos construir um teste validando a função Max(), segue:
#include "tlpp-core.th"
using namespace tlpp.probat
@TestFixture()
user function test_Max()
local nInt_1 as integer

local nInt_2 as integer
local nInt_max as integer
nInt_1 := 10
nInt_2 := 20
nInt_max := max( nInt_1, nInt_2 )
// Result , Expected
assertEquals( nInt_max, 20 )
13 https://tdn.totvs.com/display/tec/Reflection+e+Annotation
5 - Construindo Testes – 26
TOTVSTEC – PROBAT
return .T. // NOTA: Sempre retornar TRUE

• Por esse modo só temos a obrigação da annotation [TestFixture] e o uso do assertEquals(), porém tem
um custo, possui menos recursos avançados para estruturar o teste.
• Pode ser extremamente útil para testes simples que não exigem complexidade em sua funcionalidade.
• Simplifica o uso do PROBAT para quem tem dificuldades em escrever códigos com orientação a objetos.
7.2 b - Teste simples com classe

Utilizando a mesma aplicação no exemplo anterior, agora iremos implementar o mesmo teste só que utilizando
classe.
Veja o exemplo:
@TestFixture()
class test_max_class
private data nInt_1 as integer

private data nInt_max as integer
public method new() constructor
@Test('aqui deve-se colocar o descritivo sobre o teste')

public method test_Max()
endclass
method new() class test_max_class

::nInt_1 := 10
::nInt_2 := 20
return self
method test_Max() class test_max_class
::nInt_max := max( ::nInt_1, ::nInt_2 )
// Result , Expected
assertEquals( ::nInt_max, 20 )
return .T. // NOTA: Sempre retornar TRUE

Nesse exemplo não há acréscimo de funcionalidades e apenas mudou a forma de escrever o teste, fazendo uso de
classe e por consequência, uso de mais uma annotation [Test] para indicar qual método da classe deve ser
executado como teste.
TOTVSTEC – PROBAT
7.3 c - Teste completo com classe

Ao utilizar classe para escrever seu teste, é possível a utilização de mais recursos para estruturar a lógica dele.
Além das annotations já citadas, temos ainda a possibilidade de utilizar as seguintes:
[OneTimeSetUp]
Indica os métodos a serem executados somente uma vez antes de qualquer método de teste.
[SetUp]
Indica os métodos a serem executados imediatamente antes de cada método de teste.
[OneTimeTearDown]
Indica os métodos a serem executados somente uma vez após de todos os métodos de teste.
[TearDown]
Indica os métodos a serem executados imediatamente após cada método de teste.
[ErrorLog]
Indica um método que terá obrigatóriamente um error.log em tempo de execução (runtime). Esse recurso será
explicado melhor em (Recursos Avançados).
Para ficar claro, abaixo segue um exemplo com todas as annotatios para facilitar o entendimento da ordem de
execução dos métodos através do console do appserver.
Vamos a implementação:
# include "tlpp-core.th"
# include "tlpp-probat.th"
@TestFixture()
class test_max_class_completo

private data nInt_max as integer
// Setups
@OneTimeSetUp()
public method SetOne_1()
@OneTimeSetUp()
public method SetOne_2()
@Setup()
public method SetAll()
// Tests
@Test('first example test for full use of resources')
public method FirstExampleMethod()
TOTVSTEC – PROBAT
@Test('second example test for full use of resources')

public method SecondExampleMethod()
//TearDown's
@TearDown()
public method DownAll()
@OneTimeTearDown()
public method DownOne()
endclass
method new() class test_max_class_completo

::nInt_1 := 10
::nInt_2 := 20
conout( '-> [constructor] Method: ' + procname() )
return self
method SetOne_1() class test_max_class_completo

::nInt_1 += 5
::nInt_2 += 1
conout( ' -> [OneTimeSetUp] Method: ' + procname() )
return .T.
method SetOne_2() class test_max_class_completo

::nInt_1 += 3
::nInt_2 += 2
conout( ' -> [OneTimeSetUp] Method: ' + procname() )
return .T.
method SetAll() class test_max_class_completo

::nInt_1 += 5
::nInt_2 += 1
conout( ' -> [SetUp] Method: ' + procname() )
return .T.
method FirstExampleMethod() class test_max_class_completo

conout( ' -> [Test] Method: ' + procname() )
return .T.
method SecondExampleMethod() class test_max_class_completo

conout( ' -> [Test] Method: ' + procname() )
return .T.
method DownAll() class test_max_class_completo

::nInt_1 -= 2
conout( ' -> [TearDown] Method: ' + procname() )
return .T.
TOTVSTEC – PROBAT
method DownOne() class test_max_class_completo

::nInt_1 := Nil
::nInt_2 := Nil
conout( ' -> [OneTimeTearDown] Method: ' + procname() )
return .T.
Com esse exemplo, teremos a seguinte saída no console:
-> [constructor] Method: NEW | nInt_1 [10] | nInt_2 [20]

-> [OneTimeSetUp] Method: SETONE_1 | nInt_1 [15] | nInt_2 [21]
-> [OneTimeSetUp] Method: SETONE_2 | nInt_1 [18] | nInt_2 [23]
-> [SetUp] Method: SETALL | nInt_1 [23] | nInt_2 [24]
-> [Test] Method: FIRSTEXAMPLEMETHOD | nInt_1 [23] | nInt_2 [24]
-> [TearDown] Method: DOWNALL | nInt_1 [21] | nInt_2 [24]
-> [SetUp] Method: SETALL | nInt_1 [26] | nInt_2 [25]
-> [Test] Method: SECONDEXAMPLEMETHOD | nInt_1 [26] | nInt_2 [25]
-> [TearDown] Method: DOWNALL | nInt_1 [24] | nInt_2 [25]
-> [OneTimeTearDown] Method: DOWNONE | nInt_1 [ ] | nInt_2 [ ]
7.3.1 Importante
Os métodos SETONE e DOWNONE somente são executados uma única vez, ou seja, no início de todos os testes
executa o SETONE e ao final de todos os testes executa o DOWNONE.
Porém, como temos mais de 1 (um) método de teste, os métodos SETALL e DOWNALL são executados mais de uma
vez, sempre antes de cada método de teste executa o SETALL e após cada método de teste executa o DOWNALL.
O fluxo de execução da classe fica então:
1. Inicia Objeto TestFixture (método new)
2. Executa método OneTimeSetup [Opcional]
3. Executa método Setup [Opcional]
4. Executa método Test
5. Executa método TearDown [Opcional]
6. Executa método OneTimeTearDown [Opcional]
NOTA 1: não há limites para quantidade de métodos a serem executados através das marcações por annotation, ou
seja, todos os métodos marcados serão executados.
NOTA 2: Os passos 3-4-5, caso tenham sido declarados pelas annotations correspondentes e exista mais de um
teste, sempre haverá esse Loop de execução dos 3 passos, ou seja, >> setup >> test >> tearDown.
7.4 d - Asserts
Ao utilizar o PROBAT como motor de testes, é preciso fazer uso de algumas funções para que os resultados sejam
registrados corretamente.
Essas funções são chamadas de asserts, e cada uma tem uma função específica.
Abaixo segue a relação de funções de asserts disponíveis:
TOTVSTEC – PROBAT
• assertEquals(see page 31)

• assertNotEquals(see page 32)

• assertOK(see page 34)
• assertError(see page 35)
• assertWarning(see page 37)
• assertTrue(see page 38)
• assertFalse(see page 39)
• assertGreater(see page 41)
• assertGreaterOrEqual(see page 42)
• assertLess(see page 44)
• assertLessOrEqual(see page 45)
• assertIsRegExFull(see page 47)
• assertIsRegExPartial(see page 48)
• assertIsContained(see page 50)
• assertJson(see page 51)
• assertNil(see page 53)
• assertNull(see page 54)
• assertVector(see page 56)
7.4.1 assertEquals
Verifica se o resultado do teste é IGUAL ao de um valor esperado.
7.4.1.1 Sintaxe
tlpp.probat.assertEquals( < xValue >, < xExpected >, [ cDesc ] )

ou
assertEquals( < xValue >, < xExpected >, [ cDesc ] )
7.4.1.2 Parâmetros
Nome Tipo Descrição Obrigatório Referência
xValue variant Valor produzido pelo teste X
xExpected variant Valor esperado X
cDesc character Descrição do teste

(opcional)
TOTVSTEC – PROBAT
7.4.1.3 Retorno
Nome Tipo Descrição
lRet logical Indica se os valores xValue e xExpected são iguais.
7.4.1.4 Observações
• Caso o assertEquals() for chamado sem que tenha o PROBAT em execução, os valores gerados serão
somente exibidos no console.log da aplicação.
7.4.1.5 Exemplos
@TestFixture()
function sample_assertEquals()
local n1 := 10 as numeric
assertEquals( n1, n2 ) // Ok
assertEquals( n1, n3 ) // Erro
return .T.
7.4.1.6 Abrangência
01.02.10
7.4.2 assertNotEquals
Verifica se o resultado do teste é DIFERENTE ao de um valor informado.
7.4.2.1 Sintaxe
tlpp.probat.assertNotEquals( < xValue >, < xExpected >, [ cDesc ] )
TOTVSTEC – PROBAT
ou
assertNotEquals( < xValue >, < xExpected >, [ cDesc ] )
7.4.2.2 Parâmetros
xExpected variant Valor não esperado X

(opcional)
7.4.2.3 Retorno
lRet logical Indica se os valores xValue e xExpected são diferentes.
• Caso o assertNotEquals() for chamado sem que tenha o PROBAT em execução, os valores gerados serão
7.4.2.5 Exemplos
@TestFixture()
function sample_assertNotEquals()
TOTVSTEC – PROBAT
assertNotEquals( n1, n2 ) // Erro

assertNotEquals( n1, n3 ) // Ok
return .T.
01.02.10
7.4.3 assertOK
Causa um resultado OK de forma deliberada.
7.4.3.1 Sintaxe
tlpp.probat.assertOK( < cMessage > )

ou
assertOK( < cMessage > )
7.4.3.2 Parâmetros
cMessage character Mensagem de OK X

customizada
7.4.3.3 Retorno
lRet logical Sempre irá retornar verdadeiro (.T.).
TOTVSTEC – PROBAT
• Caso o assertOK() for chamado sem que tenha o PROBAT em execução, os valores gerados serão somente
exibidos no console.log da aplicação.
7.4.3.5 Exemplos
@TestFixture()
function sample_assertOK()
if ( valtype( n1 ) == 'N' )
assertOK( "valid type for variable n1" )
endif
return .T.
01.02.10
7.4.4 assertError
Causa um resultado de ERRO de forma deliberada.
7.4.4.1 Sintaxe
tlpp.probat.assertError( < cError >, [ cDesc ], [ xValue ] )

ou
assertError( < cError >, [ cDesc ], [ xValue ] )
TOTVSTEC – PROBAT
7.4.4.2 Parâmetros
cError character Mensagem de erro customizada X
cDesc character Descrição do teste (opcional)
xValue variante Valor produzido pelo teste

(opcional), caso haja a necessidade
de manter histórico
7.4.4.3 Retorno
lRet logical Sempre irá retornar falso (.F.).
• Caso o assertError() for chamado sem que tenha o PROBAT em execução, os valores gerados serão somente
7.4.4.5 Exemplos
@TestFixture()
function sample_assertError()
if ( valtype( n1 ) <> 'N' )

assertError( "invalid type for variable n1" )
endif
return .T.
TOTVSTEC – PROBAT
01.02.10
7.4.5 assertWarning
Gera log de warning na tabela PROBAT_TEST_WARNING.
7.4.5.1 Sintaxe
tlpp.probat.assertWarning( < cWarning > )

ou
assertWarning( < cWarning > )
7.4.5.2 Parâmetros
cWarning character Mensagem de warning X
7.4.5.3 Retorno
lRet logical Indica se a mensagem foi registrada
• Embora essa função seja um assert, ela não gera resultado positivo ou negativo de teste. Irá apenas gerar
uma mensagem de AVISO que no momento de exportação dos resultados será gerado um arquivo XML com
todas as mensagens, caso existam.
• Caso o assertWarning() for chamado sem que tenha o PROBAT em execução, os valores gerados serão
TOTVSTEC – PROBAT
7.4.5.5 Exemplos
@TestFixture()
user function sample_assertWarning()
assertWarning( "esse é somente um AVISO, não será gerado resultado de teste" )
return .T.
01.02.12
7.4.6 assertTrue
Verifica se o resultado do teste é Verdadeiro (.T.).
7.4.6.1 Sintaxe
tlpp.probat.assertTrue( < lValue >, [ cDesc ] )

ou
assertTrue( < lValue >, [ cDesc ] )
7.4.6.2 Parâmetros
lValue logical Valor produzido pelo teste X

(opcional)
TOTVSTEC – PROBAT
7.4.6.3 Retorno
lRet logical Indica se o valor lValue é Verdadeiro (.T.).
• Caso o assertTrue() for chamado sem que tenha o PROBAT em execução, os valores gerados serão somente
7.4.6.5 Exemplos
@TestFixture()
function sample_assertTrue()
local l1 := .F. as logical

local l2 := .T. as logical
assertTrue( l1 ) // Erro
assertTrue( l2 ) // Ok
return .T.
01.02.10
7.4.7 assertFalse
Verifica se o resultado do teste é Falso (.F.).
7.4.7.1 Sintaxe
tlpp.probat.assertFalse( < lValue >, [ cDesc ] )
TOTVSTEC – PROBAT
ou
assertFalse( < lValue >, [ cDesc ] )
7.4.7.2 Parâmetros
lValue logical Valor produzido pelo teste X

(opcional)
7.4.7.3 Retorno
lRet logical Indica se o valor lValue é Falso (.F.).
• Caso o assertFalse() for chamado sem que tenha o PROBAT em execução, os valores gerados serão somente
7.4.7.5 Exemplos
@TestFixture()
function sample_assertFalse()
local l1 := .F. as logical

local l2 := .T. as logical
assertFalse( l1 ) // Ok
assertFalse( l2 ) // Erro
TOTVSTEC – PROBAT
return .T.
01.02.10
7.4.8 assertGreater
Verifica se o resultado do teste é MAIOR ao de um valor esperado.
7.4.8.1 Sintaxe
tlpp.probat.assertGreater( < xValue >, < xLess >, [ cDesc ] )

ou
assertGreater( < xValue >, < xLess >, [ cDesc ] )
7.4.8.2 Parâmetros
xLess variant Valor utilizado na comparação X

(xValue > xLess)
7.4.8.3 Retorno
lRet logical Indica se o valor xValue é maior que xLess.
TOTVSTEC – PROBAT
• Caso o assertGreater() for chamado sem que tenha o PROBAT em execução, os valores gerados serão
7.4.8.5 Exemplos
@TestFixture()
function sample_assertGreater()
assertGreater( n1, n2 ) // Erro

assertGreater( n2, n1 ) // Ok
return .T.
01.02.10
7.4.9 assertGreaterOrEqual
Verifica se o resultado do teste é MAIOR OU IGUAL ao de um valor esperado.
7.4.9.1 Sintaxe
tlpp.probat.assertGreaterOrEqual( < xValue >, < xLess >, [ cDesc ] )

ou
assertGreaterOrEqual( < xValue >, < xLess >, [ cDesc ] )
TOTVSTEC – PROBAT
7.4.9.2 Parâmetros
xLess variant Valor utilizado na comparação X

(xValue >= xLess)
7.4.9.3 Retorno
lRet logical Indica se o valor xValue é maior ou igual que xLess.
• Caso o assertGreaterOrEqual() for chamado sem que tenha o PROBAT em execução, os valores gerados
serão somente exibidos no console.log da aplicação.
7.4.9.5 Exemplos
@TestFixture()
function sample_assertGreaterOrEqual()
assertGreaterOrEqual( n1, n2 ) // Ok
assertGreaterOrEqual( n1, n3 ) // Erro
assertGreaterOrEqual( n3, n1 ) // Ok
return .T.
TOTVSTEC – PROBAT
01.02.10
7.4.10 assertLess
Verifica se o resultado do teste é MENOR ao de um valor esperado.
7.4.10.1 Sintaxe
tlpp.probat.assertLess( < xValue >, < xGreater >, [ cDesc ] )

ou
assertLess( < xValue >, < xGreater >, [ cDesc ] )
7.4.10.2 Parâmetros
xGreater variant Valor utilizado na comparação X

(xValue < xGreater)
7.4.10.3 Retorno
lRet logical Indica se o valor xValue é menor que xGreater.
• Caso o assertLess() for chamado sem que tenha o PROBAT em execução, os valores gerados serão somente
TOTVSTEC – PROBAT
7.4.10.5 Exemplos
@TestFixture()
function sample_assertLess()
assertLess( n1, n2 ) // Ok
assertLess( n2, n1 ) // Erro
assertLess( n1, n3 ) // Erro
return .T.
01.02.10
7.4.11 assertLessOrEqual
Verifica se o resultado do teste é MENOR OU IGUAL ao de um valor esperado.
7.4.11.1 Sintaxe
tlpp.probat.assertLessOrEqual( < xValue >, < xGreater >, [ cDesc ] )

ou
assertLessOrEqual( < xValue >, < xGreater >, [ cDesc ] )
TOTVSTEC – PROBAT
xGreater variant Valor utilizado na comparação X

(xValue <= xGreater)
7.4.11.3 Retorno
lRet logical Indica se o valor xValue é menor ou igual que xGreater.
• Caso o assertLessOrEqual() for chamado sem que tenha o PROBAT em execução, os valores gerados serão
7.4.11.5 Exemplos
@TestFixture()
function sample_assertLessOrEqual()
assertLessOrEqual( n1, n2 ) // Ok
assertLessOrEqual( n2, n1 ) // Erro
assertLessOrEqual( n1, n3 ) // Ok
return .T.
TOTVSTEC – PROBAT
01.02.10
7.4.12 assertIsRegExFull
Verifica se o valor produzido pelo teste coincide em sua totalidade com a expressão regular informada.
7.4.12.1 Sintaxe
tlpp.probat.assertIsRegExFull( < cValue >, < cPattern >, [ cDesc ] )

ou
assertIsRegExFull( < cValue >, < cPattern >, [ cDesc ] )
cValue character Valor produzido pelo teste X
cPattern character Pattern da expressão regular X

que valida todo o conteúdo de
"cValue"
7.4.12.3 Retorno
lRet logical Indica se o valor coincide totalmente com a expressão

regular.
TOTVSTEC – PROBAT
• Caso o assertIsRegExFull() for chamado sem que tenha o PROBAT em execução, os valores gerados serão
7.4.12.5 Exemplos
@TestFixture()
function sample_assertIsRegExFull()
assertIsRegExFull( "So tem letras", "[A-Za-z ]+" ) // Ok

assertIsRegExFull( "Tem 1 numero" , "[A-Za-z ]+" ) // Erro
return .T.
01.02.10
7.4.13 assertIsRegExPartial
Verifica se o valor produzido pelo teste coincide em parte com a expressão regular.
7.4.13.1 Sintaxe
tlpp.probat.assertIsRegExPartial( < cValue >, < cPattern >, [ cDesc ] )

ou
assertIsRegExPartial( < cValue >, < cPattern >, [ cDesc ] )
TOTVSTEC – PROBAT
cPattern character Pattern da expressão regular X

que valida o conteúdo de
"cValue"
7.4.13.3 Retorno
lRet logical Indica se o valor coincide parcialmente com a expressão

regular.
• Caso o assertIsRegExPartial() for chamado sem que tenha o PROBAT em execução, os valores gerados serão
7.4.13.5 Exemplos
@TestFixture()
function sample_assertIsRegExPartial()
assertIsRegExPartial( "123 tem letras e numeros 456 tambem", "[A-Za-z ]+" ) //

OK
assertIsRegExPartial( "So tem letras" , "[0-9]+" ) //
Erro
return .T.
TOTVSTEC – PROBAT
01.02.10
7.4.14 assertIsContained
Verifica se o valor produzido (string) pelo teste contém uma string determinada.
7.4.14.1 Sintaxe
tlpp.probat.assertIsContained( < cValue >, < cExpected >, [ cDesc ] )

ou
assertIsContained( < cValue >, < cExpected >, [ cDesc ] )
cExpected character Valor que deve estar contido X

em "cValue"
7.4.14.3 Retorno
lRet logical Retorna o resultado de ( cExpected $ cValue )
• Caso o assertIsContained() for chamado sem que tenha o PROBAT em execução, os valores gerados serão
TOTVSTEC – PROBAT
7.4.14.5 Exemplos
@TestFixture()
function sample_assertIsContained()
local c1 := "the value is correct" as character

local c2 := "the value is invalid" as character
local cExpected := "invalid" as character
assertIsContained( c1, cExpected ) // Erro

assertIsContained( c2, cExpected ) // Ok
return .T.
01.02.10
7.4.15 assertJson
Verifica se o resultado do teste em Json é IGUAL ao de um json esperado.
7.4.15.1 Sintaxe
tlpp.probat.assertJson( < xValue >, < xExpected >, [ cDesc ] )

ou
assertJson( < xValue >, < xExpected >, [ cDesc ] )
TOTVSTEC – PROBAT
jValue json Valor produzido pelo X

teste
xExpected json ou character Valor esperado X

(opcional)
7.4.15.3 Retorno
lRet logical Indica se os valores jValue e xExpected são iguais.
• Caso o assertJson() for chamado sem que tenha o PROBAT em execução, os valores gerados serão somente
7.4.15.5 Exemplos
# include "tlpp-core.th"
# include "tlpp-probat.th"
@TestFixture()
function sample_assertJson()
local oJson1 as json

local cJson1 as character
cJson1 := '{"key":"value"}'
cJson2 := cJson1
cJson3 := '{"key":"value_1"}'
TOTVSTEC – PROBAT
oJson1 := JsonObject():New()
oJson1:fromJson( cJson1 )
assertJson( oJson1, oJson2 ) // Ok

assertJson( oJson1, oJson3 ) // Erro
assertJson( oJson1, cJson2 ) // Ok
assertJson( oJson1, cJson3 ) // Erro
return .T.
01.02.10
7.4.16 assertNil
Verifica se o resultado do teste é Nil (Nulo).
7.4.16.1 Sintaxe
tlpp.probat.assertNil( < xValue >, [ cDesc ] )

ou
assertNil( < xValue >, [ cDesc ] )
TOTVSTEC – PROBAT

(opcional)
7.4.16.3 Retorno
lRet logical Indica se o valor xValue é Nil (Nulo).
• Caso o assertNil() for chamado sem que tenha o PROBAT em execução, os valores gerados serão somente
7.4.16.5 Exemplos
@TestFixture()
function sample_assertNil()
local u1
local c3 := 'abc' as character
assertNil( u1 ) // Ok
assertNil( n2 ) // Erro
assertNil( c3 ) // Erro
return .T.
01.02.10
7.4.17 assertNull
Verifica se o resultado do teste é Nil (Nulo).
TOTVSTEC – PROBAT
7.4.17.1 Sintaxe
tlpp.probat.assertNull( < xValue >, [ cDesc ] )

ou
assertNull( < xValue >, [ cDesc ] )

(opcional)
7.4.17.3 Retorno
lRet logical Indica se o valor xValue é Nil (Nulo).
• Caso o assertNull() for chamado sem que tenha o PROBAT em execução, os valores gerados serão somente
7.4.17.5 Exemplos
@TestFixture()
function sample_assertNull()
TOTVSTEC – PROBAT
local u1
local c3 := 'abc' as character
assertNull( u1 ) // Ok
assertNull( n2 ) // Erro
assertNull( c3 ) // Erro
return .T.
01.02.10
7.4.18 assertVector
Verifica se o resultado do teste é um Vetor (array) IGUAL ao de um Vetor esperado.
7.4.18.1 Sintaxe
tlpp.probat.assertVector( < aValue >, < aExpected >, [ cDesc ] )

ou
assertVector( < aValue >, < aExpected >, [ cDesc ] )
aValue array Vetor (array) produzido pelo X

teste
aExpected array Vetor (array) esperado X

(opcional)
TOTVSTEC – PROBAT
7.4.18.3 Retorno
lRet logical Indica se os vetores (array) aValue e aExpected são iguais em

todos os seus elementos.
• O assertVector() somente compara vetores. Ele não é capaz de comparar array multidimensionais.
• Caso o assertVector() for chamado sem que tenha o PROBAT em execução, os valores gerados serão
7.4.18.5 Exemplos
@TestFixture()
function sample_assertVector()
local a1 := {1,2,'3', ,date()} as array

local a2 := {1,2,'3', ,date()} as array
local a3 := {1,2,'3',4,date()} as array
assertVector( a1, a2 ) // Ok
assertVector( a1, a3 ) // Erro
return .T.
01.02.10
7.5 e - Recursos Avançados

Veja a seguir recursos avançados para implementar em seus testes:
• e-1 - A Annotation TestFixture(see page 58)

• e-2 - Execução em thread(see page 62)
• e-3 - Ordem e Prioridade(see page 63)
• e-4 - Pulando Testes(see page 65)
TOTVSTEC – PROBAT
• e-5 - Suites(see page 69)

• e-6 - Cobertura de Código(see page 71)

• e-7 - Error Log(see page 78)
• e-8 - Cross Validation(see page 79)
7.5.1 e-1 - A Annotation TestFixture

Como vimos anteriormente, a marcação de uma função ou classe como Teste do PROBAT é feita pela
annotation [TestFixture], porém ela possui muito mais funcionalidades além dessa marcação.
Vejamos:
7.5.1.1 SUITE
A propriedade "suite" indica para qual suite o teste pertence, porém caso não seja informado através da
annotation, o PROBAT adiciona o teste para o SUITE ALL.
Caso queira adicionar a outro suite, é preciso informar explicitamente essa propriedade.
Tipo Valor Default
character "all"
Exemplos
Executa em Modo All:

@TestFixture() // Como "ALL" é o valor default, não há necessidade de informá-lo
ou
@TestFixture(suite="all")
ou
@TestFixture("all")
Criando uma suite:

@TestFixture(suite="minha_suite")
ou
@TestFixture("minha_suite")
NOTA:
A forma não nomeada é possível para a propriedade [suite] pois ela é a primeira propriedade descrita na
Annotation.
Essa forma só é possível para [suite], as demais propriedades precisam obrigatoriamente ser nomeadas.
TOTVSTEC – PROBAT
7.5.1.2 OWNER
A propriedade "owner" indica quem é o "proprietário" do teste.
Sem informar, ele grava como Owner = "Unknown"
Tipo Valor Default
character "unknown"
Exemplo:
@TestFixture(owner="tlpp")
Com isso indico que o TLPP é "proprietário" desse teste.

Até o momento dessa versão, esse recurso somente registra o "proprietário" no SQLite, pois necessita a
implementação para uso de filtros e agrupamentos de resultados por "proprietário".
7.5.1.3 THREAD
Indica se no momento da execução do teste o PROBAT irá abrir uma Thread exclusiva para que o teste seja
executado.
Tipo Valor Default
character "yes"
Exemplos
Abre Thread:
@TestFixture() // Como "yes" é o valor default, não há necessidade de informá-lo
ou
@TestFixture(thread="yes")
NÃO abre Thread:

@TestFixture(thread="no")
TOTVSTEC – PROBAT
7.5.1.4 PRIORITY
Modifica a prioridade na execução dos testes, permitindo que o desenvolvedor possa indicar a ordem de execução
conforme suas necessidades.
Tipo Valor Default
numeric 100
Exemplos
Prioridade ALTA:
@TestFixture(priority=0)
Prioridade BAIXA:
• Os números possíveis para informar é de 0 a 999, somente 3 caracteres.

• Não são permitidos números negativos.
Saiba mais sobre ordem de execução dos testes em [Ordem e Prioridade(see page 63)]
7.5.1.5 FOLDER
A propriedade "folder" indica o diretório onde se encontra fisicamente o teste.
Tipo Valor Default
character ""
Porém, essa informação é facultativa pois o folder pode ser detectado automaticamente caso esteja utilizando
boas práticas de desenvolvimento através de namespaces, como o exemplo abaixo:
Localização física arquivo Namespace
/test/date test.date
Caso você não queria utilizar namespaces em seu projeto, você pode contornar essa detecção automática
informando explicitamente o diretório de seu teste, conforme abaixo:
TOTVSTEC – PROBAT
@TestFixture(folder="/test/date")
7.5.1.6 TEST
A propriedade "test" se refere ao nome do teste, por boas práticas o relacionamos à funcionalidade a ser testada.
Tipo Valor Default
character ""
Porém, essa informação é facultativa pois o nome pode ser extraído automaticamente do nome da classe e/ou
função de teste.
Por exemplo, ao criarmos o teste para a classe LOGS, criaríamos então um arquivo fonte de teste com o nome:
test_LOGS.
Nesse caso, o PROBAT irá extrair o nome como: "LOGS"
Porém, caso queria dar um nome diferente do extraído automaticamente, pode-se utilizar a propriedade "test".
Exemplo:
@TestFixture(test='logs_customizados')
class test_LOGS
7.5.1.7 DESCRIPTION
Informa uma descrição para o Teste caso haja a necessidade.
Tipo Valor Default
character ""
Exemplo:
@TestFixture(description="coloque aqui seu texto explicando o teste")
7.5.1.8 TARGET
Informa qual o "alvo" do teste, na qual foi informado pelo Cross-Validation.
TOTVSTEC – PROBAT
Tipo Valor Default
character ""
Exemplo:
@TestFixture(target="item.1")
Veja mais detalhes desse recurso em: Cross-Validation(see page 79)
7.5.1.9 - RUNWITHALL | RWA

Determina se Teste será executado com suite ALL ou se sua execução é obrigatório do modo exclusivo
Tipo Valor Default
logical .T.
Exemplos
Executa em Modo All:

@TestFixture() // Como .T. é o valor default, não há necessidade de informá-lo
ou
@TestFixture(runWithAll=.T.)
ou
@TestFixture(rwa=.T.)
NÃO executa em Modo All:

@TestFixture(runWithAll=.F.)
ou
@TestFixture(rwa=.F.)
7.5.2 e-2 - Execução em thread

O PROBAT por default abre uma thread apartada da execução principal para melhor controle de erros, pois dessa
forma, ao ocorrer um error.log na execução do teste o PROBAT tem a capacidade de capturar esse erro e continuar
com a execução dos demais testes sem interrupção do motor de testes.
TOTVSTEC – PROBAT
Porém, pode ser que um recurso ou outro não possa ser executado com o uso de StartJob() do appserver, então
nesse caso o desenvolvedor tem a possibilidade de informar ao PROBAT de que deseja que o teste seja executado
na mesma Thread do motor de testes.
Contudo há um risco envolvido nesse processo, pois se houver um error.log no teste e não for possível a captura do
erro, todo a execução do PROBAT será interrompida pois a Thread principal será derrubada.
Por isso demos esse controle nas mãos do desenvolvedor, pois ele determina através de uma propriedade da
annotation [TestFixture] conforme necessidade e tem controle dos riscos.
Veja os exemplos abaixo.
7.5.2.1 * Abre a Thread:

@TestFixture()
ou
@TestFixture(thread="yes")
7.5.2.2 * NÃO abre a Thread:

@TestFixture(thread="no")
Todos os testes marcados com [thread="no"] serão somente executados ao final de todos os demais testes,
justamente para diminuir os riscos já citados acima.
7.5.3 e-3 - Ordem e Prioridade

Os testes escritos com PROBAT são localizados no RPO através das funções de Reflection, portanto a ordem de
retorno das Reflections incidirá sobre a ordem de execução dos testes, pois será também a ordem de gravação na
tabela PROBAT_CONFIG_ROUTINES no SQLite.
Se algum dia a lógica da ordem de retorno das Reflections mudar, irá mudar também a ordem para o PROBAT.
Ou seja, se não for usado nenhum outro recurso do PROBAT, essa será a ordem de execução dos testes.
Porém, ainda existem alguns recursos que podem ser usados para mudar a ordem de execução conforme convém,
sendo:
• [TestFixture >> Priority] - Mudar a prioridade do Teste;
• [TestFixture >> Thread] - Informar que o Teste não deve ser em nova Thread.
7.5.3.1 1 - Prioridade
Esse recurso especificamente é usado somente para mudar a ordem de execução dos testes, e é muito simples
usar.
Os valores informados em [TestFixture >> Priority] devem ser:
• Ser do tipo [numeric].
• Estar entre 0 e 999, ou seja, até 3 dígitos.
TOTVSTEC – PROBAT
• Não podem ser negativos.

Para isso, basta usar a propriedade [priority] da annotation [TestFixture], vejamos:
@TestFixture()
user function teste_1()
@TestFixture()
@TestFixture()
Nesse caso, como todos os testes possuem a mesma prioridade (100 é o valor default), serão executados na
seguinte ordem:
1o. - teste_1()
2o. - teste_2()
3o. - teste_3()
Agora, vamos aplicar a prioridade e vejamos o que acontece:
@TestFixture()
Teremos então a seguinte ordem:
1o. - teste_3()
2o. - teste_1()
3o. - teste_2()
7.5.3.2 2 - Thread
Embora esse recurso não tem a finalidade de organizar a ordem de execução dos testes, na prática acaba alterando
pois todos os testes "marcados" para não abrir uma Thread destacada serão executados ao final para amenizar o
risco de ocorrer um error.log e derrubar as demais execuções.
Portanto, não é aconselhado usar esse recurso para manipular a ordem, mas é bom saber que os testes com
@TestFixture[thread="no"] sejam lançadas ao final de todos os testes.
Saiba mais sobre esse recurso em (Execução em thread(see page 62)).
TOTVSTEC – PROBAT
7.5.4 e-4 - Pulando Testes

É possível "pular" alguns testes escritos para o PROBAT, esse recurso embora deva ser evitado ao máximo pois um
teste deve ser executado sempre e sua finalidade é forçar as correções.
Porém, algumas correções ou pendências podem demorar muito para ocorrer por muitas causas e nesse caso não
faz sentido termos o plano de testes quebrando por uma pendência na qual não tenhamos gerência para mudar,
por exemplo.
Outro exemplo é realizar o "pulo" para determinadas versões do appserver, tlppCore ou SO específico. Esse recurso
veremos ao final dessa mesma página.
Portanto o PROBAT embora "pule" a execução do testes, o salto será registrado, e mesmo não quebrando os
resultados irá exportar a informação do teste como "skipped".
Bom, vamos ver como podemos marcar um teste como "skip".
Para exemplos completos, veja em (Exemplo no GitHub(see page 102))
7.5.4.1 Pulando Funções e Métodos inteiros - @Skip()

Esse recurso causa o "pulo" da função ou método inteiro, independentemente de quantas funções de asserts
existem implementados em seu escopo.
Portanto, mesmo que hajam muitos asserts implementados, quando houver @skip() o PROBAT irá registrar
somente 1 (um) salto no resultado de testes, pois ele irá fazer referência à função ou ao método e não ao seu
conteúdo.
Exemplos:
Usando função:
@TestFixture()
@Skip()
user function test_sample_skip()
...
Usando classe:
@TestFixture()
@Skip()
public method test_sample_skip()
...
7.5.4.2 Pulando asserts específicos - SKIPASSERT e SKIPTEST

Ao contrário da opção acima, talvez seja necessário somente "pular" um assert em específico e não o teste inteiro.
Para isso existe um comando que é inserído em seu fonte logo antes da execução do assert.
TOTVSTEC – PROBAT
O "pulo" ficará condicionado a somente ao próximo assert que for executado, sendo assim, o assert posterior será
executado normalmente.
Igualmente ao @Skip(), o PROBAT irá registar o salto no resultado dos testes sem gerar resultado negativo, porém
agora ele fará referência ao assert "pulado".
Exemplo:
Usaremos no exemplo uma função, mas o procedimento pode ser usado em método também pois esse recurso é
por assert.
Usando função:


@TestFixture()
user function test_sample_skip_assert()

local cVar := "" as character
local nVar := 0 as numeric
local fVar as decimal

assertEquals( valtype(cVar), "C" )

SKIPTEST
assertEquals( valtype(fVar), "F" )
// OU
SKIPASSERT
assertEquals( valtype(fVar), "F" )

assertEquals( valtype(nVar), "N" )

return .T.
7.5.4.3 Utilizando filtros para o Skip

O recurso de salto possui a possibilidade de informar algumas circunstâncias que o teste deve ser "pulado",
seguem:
• Sistema Operacional;
• Versão tlppCore;
• Versão appserver;
• Nome appserver.
O recurso funciona tanto para a annotation [Skip] como para os comandos [SKIPTEST] e [SKIPASSERT].
Vejamos os exemplos:
TOTVSTEC – PROBAT
Sistema Operacional:
@Skip()
@Skip( system="windows" ) // Somente pula o teste em Sistema Operacional WINDOWS

// ou

@Skip( system="linux" ) // Somente pula o teste em Sistema Operacional LINUX
Comando Skip do assert
// Somente pula o assert em Sistema Operacional WINDOWS

SKIPASSERT SYSTEM "windows"
// ou
SKIPTEST SYSTEM "windows"

// Somente pula o assert em Sistema Operacional LINUX
SKIPASSERT SYSTEM "linux"
// ou
SKIPTEST SYSTEM "linux"
Versão tlppCore:
@Skip()
@Skip( tlppVersion="01.02.10" ) // Somente a versão 01.02.10

// ou

@Skip( tlppVersion="< 01.02.12" ) // Todas as versões abaixo de 01.02.12

// ou

@Skip( tlppVersion=">= 01.02.12" ) // Todas as versões acima e igual de 01.02.12
// Somente a versão 01.02.10

SKIPASSERT TLPPVERSION "01.02.10"
// ou
TOTVSTEC – PROBAT
SKIPTEST TLPPVERSION "01.02.10"


// Todas as versões abaixo de 01.02.12
SKIPASSERT TLPPVERSION "< 01.02.12"
// ou
SKIPTEST TLPPVERSION "< 01.02.12"

// Todas as versões acima e igual de 01.02.12
SKIPASSERT TLPPVERSION ">= 01.02.12"
// ou
SKIPTEST TLPPVERSION ">= 01.02.12"
Versão appserver:
@Skip()
@Skip( appServerVersion="19.3.1.5" ) // Somente a versão 19.3.1.5

// ou

@Skip( appServerVersion="< 19.3.1.7" ) // Todas as versões abaixo de 19.3.1.7

// ou

@Skip( appServerVersion=">= 19.3.1.7" ) // Todas as versões acima e igual de 19.3.1.7
// Somente a versão 19.3.1.5

SKIPASSERT APPSERVERVERSION "19.3.1.5"
// ou
SKIPTEST APPSERVERVERSION "19.3.1.5"

// Todas as versões abaixo de 19.3.1.7
SKIPASSERT APPSERVERVERSION "< 19.3.1.7"
// ou
SKIPTEST APPSERVERVERSION "< 19.3.1.7"

// Todas as versões acima e igual de 19.3.1.7
SKIPASSERT APPSERVERVERSION ">= 19.3.1.7"
// ou
SKIPTEST APPSERVERVERSION ">= 19.3.1.7"
TOTVSTEC – PROBAT
Nome appserver:
@Skip()
@Skip( appServerName="LOBO-GUARA" ) // Somente pula o teste em appserver LOBO-GUARA

// ou

@Skip( appServerName="HARPIA" ) // Somente pula o teste em appserver HARPIA
// Somente pula o teste em appserver LOBO-GUARA

SKIPASSERT APPSERVERNAME "LOBO-GUARA"
// ou
SKIPTEST APPSERVERNAME "LOBO-GUARA"

// Somente pula o teste em appserver HARPIA
SKIPASSERT APPSERVERNAME "HARPIA"
// ou
SKIPTEST APPSERVERNAME "HARPIA"
IMPORTANTE
É possível juntar mais de uma opção no mesmo SKIP.
Exemplos:
@Skip( system="linux", appServerName="HARPIA" )

// ou

SKIPASSERT SYSTEM "linux" APPSERVERNAME "HARPIA"

// ou

SKIPTEST SYSTEM "linux" APPSERVERNAME "HARPIA"
• Pode juntar as 4 (quatro) opções de filtro.

• Toda vez que tiver mais de uma opção o operador utilizado é o "AND", ou seja, todas as opções precisam
ser válidas para entrar no filtro, caso contrário o teste não será "pulado".
7.5.5 e-5 - Suites

Uma Suíte de Testes é uma coleção de casos de testes que são agrupados para propósitos de execução de testes.
TOTVSTEC – PROBAT
Todos os testes escritos para o PROBAT devem pertencer a uma suíte de testes, sendo assim, o desenvolvedor
pode informar explicitamente qual suíte ele pertence ou, não informar nada e manter o valor default, ou seja, a
suíte "ALL" (todos).
Exemplo:
@TestFixture()
user function test_sample_suite()
...
return .T.
O exemplo acima automaticamente será adicionado na suíte "ALL"
7.5.5.1 Suítes customizadas

O desenvolvedor pode criar suítes customizadas conforme necessidade.
Por exemplo, pode-se agrupar testes que sejam da suíte "financeiro", outros da suíte "compras" e assim por
adiante.
Ou então, podemos agrupar por "manipulação de arquivo", "apis de integração", "sys_log", etc...
Veja que ele é flexível para atender as mais diversas necessidades, portanto, quais suítes deverão ser criadas será
definido por cada equipe de desenvolvimento.
Para criar, é muito simples:
@TestFixture( suite='sistemico' )
Basta utilizar a propriedade SUITE e informar o nome que desejar.

Nesse caso, criamos uma suíte chamada de "sistemico", e nela podemos agrupar todos os testes que precisam ser
executados para os testes sistêmicos de um produto.
Uma das vantagens de se organizar os testes por suítes, é que torna possível a execução dos testes somente de uma
suíte em específico, informando então na função de RUN que deseja somente executar a suíte "sistemico".
Veja em mais detalhes os modos de execução em (Executando Testes).
Um ponto importante também a se saber é que, por default, mesmo sendo uma suíte customizada ela será
executada no modo ALL a função RUN, ou seja, ao solicitar que todos os testes sejam executados o PROBAT irá
executar todas as suítes customizadas também.
Exceto se o desenvolvedor indicar explicitamente de que uma determinada suíte é exclusiva.
Veja mais abaixo:
7.5.5.2 Suítes Exclusivas

Utilizando o exemplo de cima, podemos informar ao PROBAT que a suíte "sistemico" não pode ser executada no
modo ALL, portanto, somente será executada quando for explicitamente informada na função RUN.
Esse recurso é interessante para dar mais flexibilidade ao projeto, e usando mais uma vez o exemplo, a suíte
"sistemico" não pode ser executada a cada validação de commits feitos ao projeto. São testes que somente devem
ser executados no período de testes Sistêmicos e portanto devem ser exclusivos.
TOTVSTEC – PROBAT
Para indicar que uma suíte é exclusiva, é muito simples.

Sugerimos criar um código fonte somente para essas configurações que o PROBAT permite, portanto, sugerimos:
test_config.tlpp
E agora, dentro dele coloque a seguinte instrução:
#include 'tlpp-probat.th'

SUITE sistemico EXCLUSIVE
Agora é só compilar o test_config.tlpp e pronto, ele não será mais executado em

modo ALL.
7.5.6 e-6 - Cobertura de Código

Escrevemos nossos testes esperando avaliar a qualidade das nossas aplicações, descobrindo se as funcionalidades
estão corretas ou não. Porém, como saber se tais testes estão percorrendo todas as linhas codificadas de nossos
projetos?
Os testes passam por todos os caminhos (felizes, infelizes, alternativos ou inesperados) ? Todos os fluxos possíveis
estão sendo testados?
Como saberemos se nosso código possui trechos sem utilidade e/ou que são inalcançáveis?
Não há como saber apenas olhando para os resultados dos testes, por isso será necessário utilizar os conceitos de
Cobertura de Código para responder esses questionamentos.
A Cobertura de Código nos propicia a utilização de métricas claras para obtenção do percentual de cobertura,
como também é possível analisar visualmente seu código-fonte e observar de forma simples quais linhas foram
executadas e quais linhas deixaram de ser testadas.
O PROBAT possui recursos suficientes para geração dos resultados de cobertura de código necessários para
aprimorar a qualidade dos testes.
7.5.6.1 Ativando a Cobertura

Para acessá-los, é preciso primeiro ativar o recurso através da configuração do PROBAT, portanto basta na INI
modificar as seguintes chaves:
[PROBAT]
CODECOVERAGE=1
O valor da chave [CODECOVERAGE] deve ser numérico, sendo (0=desligado) e (1=ligado)
Essa chave irá informar ao PROBAT que agora ele deverá ativar e registrar a cobertura de código de cada Teste
executado.
Vale lembrar que a captação da informação de cobertura de código em tempo de execução é responsabilidade do
appserver e ao PROBAT cabe avisar o appserver para captar esses valores e após isso, quantificar os valores,
registrar os dados, validar os testes e gerar as exportações conforme configurações da Cobertura.
Nota: a chave acima somente liga a Captação e registro dos resultados nas tabelas do SQLite
TOTVSTEC – PROBAT
7.5.6.2 Recursos
Ao ativar, podemos ter acesso aos seguintes recursos:
• Consolidação de Resultados(see page 72)
• Persistência em SQLite
• Valores sintéticos e analíticos
• Exportação(see page 74)
• XML
• JSON
• Validação(see page 77)
• Percentual mínimo de cobertura
• Filtro por módulo
• Modificando % por fonte
• Extensão VsCode(see page 75)
• Visualização Cobertura por fonte
7.5.6.3 Consolidação de Resultados

Ao ligar esse recurso, ao final dos testes os resultados de cobertura serão persistidos em SQLite, portanto podem
ser consultados posteriormente, basta apenas acessar as tabelas descritas abaixo:
Importante ressaltar que o PROBAT somente registra a última execução de cobertura de código em SQLite.
Tabelas no SQLite
Possuímos 3 (três) tabelas contendo dados de cobertura dos fontes.
Nome tabela Descrição
PROBAT_CODECOVERAGE_TOTAL Percentual Total de cobertura sumarizado por todos os

fontes
PROBAT_CODECOVERAGE_SOURCES Percentual Total de cobertura por fonte
PROBAT_CODECOVERAGE_LINES Informação linha a linha por fonte sobre a cobertura
Abaixo, podemos ver a estrutura de cada tabela.
PROBAT_CODECOVERAGE_TOTAL
Campo Tipo Descrição
CODE_EXEC C Código interno da execução dos testes
SOURCES N Quantidade TOTAL de fontes percorridos pela

Cobertura
TOTVSTEC – PROBAT
LINES N Quantidade TOTAL de linhas percorridos pela

Cobertura
COVERAGE N Percentual TOTAL de Cobertura, considerando fontes

oficiais e testes
COVERAGE_FRAME N Percentual TOTAL de Cobertura de SOMENTE dos

fontes oficiais
COVERAGE_TEST N Percentual TOTAL de Cobertura de SOMENTE dos

fontes de testes
PROBAT_CODECOVERAGE_SOURCES
RUN C 0 = Fonte não foi executado durante os testes, 1 = Fonte

foi executado
CODE_SRC N Código interno do fonte oficial
CODE_TST N Código interno do fonte de teste
SOURCE C Nome do fonte
LINES N Quantidade total de linhas do fonte
COVERAGE N Percentual de Cobertura para esse fonte
PROBAT_CODECOVERAGE_LINES
CODE_SRC N Código interno do fonte oficial
CODE_TST N Código interno do fonte de teste
TOTVSTEC – PROBAT
SOURCE C Nome do fonte
LINE C Número da linha
COVERAGE N Cobertura: -1 = Linha não Debugável, 0 = Não executou a

linha, >0 = Quantidade de vezes que executou a linha
durante os testes
CHANGE C Em algum momento o appserver trocou a informação se a

linha é ou não debugável, indicando bug, sendo: 0 =
Comportamento Correto, 1 = Bug
Conclusão
Como podemos observar, temos informações com diversos espectros para análise da Cobertura de Código de
nosso projeto, portanto:
Considerando a tabela PROBAT_CODECOVERAGE_TOTAL, conseguimos ter uma visão sintética da Cobertura de
forma geral, obtendo os percentuais: Total (todos os fontes), Total por Fontes Oficiais e Total por Fontes de testes,
nos possibilitando tomar algumas decisões automatizadas.
Ao olhar para a tabela PROBAT_CODECOVERAGE_SOURCES, temos uma visão intermediária entre a sintética e a
analítica, nos possibilitando enxergar a cobertura de código por cada fonte de nosso projeto, seja ele oficial ou de
teste.
Agora, quando olhamos para a tabela PROBAT_CODECOVERAGE_LINES temos a visão analítica de cada fonte, nos
dando a possibilidade de saber linha a linha de todos os nossos fontes, se foram ou não executadas. Assim,
podemos melhorar nossos fontes oficiais e também os testes para aumentar a qualidade e/ou cobertura, ou
descobrir implementações dos fontes oficiais que são desnecessárias ou inalcançáveis.
7.5.6.4 Exportação
Os resultados de cobertura de código apurada podem ser exportadas de duas maneiras:
• XML no formato COBERTURA;
• JSON para uso pela extensão do VsCode.
XML
O XML pode ser usado por qualquer ferramenta de mercado que entenda o formato padronizado pelo projeto
COBERTURA. Veja mais em (https://cobertura.github.io/cobertura/).
Para solicitar a exportação no formato COBERTURA, é simples, basta seguir a configuração no INI abaixo:
[PROBAT]
CODECOVERAGE=1
O valor da chave [CODECOVERAGE_EXPORT_TFS] devem ser (0=não exporta) ou (1=exporta)
TOTVSTEC – PROBAT
JSON
Essa exportação será usada para a extensão do VsCode, pois com base nela o VsCode irá mostrar visualmente a
cobertura no fonte aberto.
Nota: A extensão está em desenvolvimento e em breve disponibilizaremos oficialmente para uso.
Porém, esse formato pode ser usado além do VsCode, pois json é um formato amplamente conhecido e de fácil
utilização por qualquer ferramenta de mercado.
Para solicitar a exportação no formato JSON, é simples, basta seguir a configuração no INI abaixo:
[PROBAT]
CODECOVERAGE=1
O valor da chave [CODECOVERAGE_EXPORT_JSON] devem ser (0=não exporta) ou (1=exporta)
7.5.6.5 Extensão VsCode

A extensão para VsCode do PROBAT permite que possamos analisar visualmente linha a linha a cobertura de
código obtida através da execução dos testes.
Para que funcione corretamente, é preciso que o PROBAT tenha gerado um arquivo JSON com os dados dos fontes
e suas respectivas coberturas, além disso é preciso configurar no VsCode a localização e nome do arquivo.
Download
A extensão ainda não foi lançada oficialmente na loja da VsCode, porém é possível obtê-la baixando o arquivo de
instalação (VSIX) através do link abaixo.
Versão Arquivo
v0.0.2 probat-0.0.2.vsix14
Instalando
Após obter o arquivo .vsix do PROBAT, recomendamos seguir a documentação oficial do VsCode com os passos
para a instalação da extensão.
Acesse a página: https://code.visualstudio.com/docs/editor/extension-marketplace#_install-from-a-vsix
Configurando
Como dito anteriormente, temos que informar ao VsCode onde encontrar o arquivo JSON gerado pelo PROBAT
com as informações de Cobertura.
1 - Tecle [Ctrl + ,] para acessar a tela de configuração do VsCode;
2 - Selecione as configurações da [Workspace];
3 - Vá em [Extensions];
14 https://tdn.totvs.com/download/attachments/687762745/probat-0.0.2.vsix?api=v2&modificationDate=1653421556713&version=1
TOTVSTEC – PROBAT
4 - Procure a seção [PROBAT];

5 - Informe em [Coverage: File] o arquivo gerado pelo PROBAT.

Conforme figura abaixo:
Visualizando a Cobertura
Após a configuração, agora é possível visualizar a cobertura sobre seus código, desde que a informação tenha sido
gerada no arquivo JSON.
Pra isso, siga os passos:
1 - Abra o arquivo que deseja visualizar a Cobertura;
2 - Após abrir, digite: [Ctrl + Shift + P ] para abrir a caixa de comandos;
3 - Digite: [PROBAT - Show Code Coverage];
OK
Caso tudo esteja OK, a extensão irá decorar seu fonte com cores distintas e teremos algo como:
Sendo:
• Linhas Cobertas: Cor Verde
• Linhas NÃO Cobertas: Cor Vermelha
• Linhas não debugáveis: sem decoração, nada muda.
Erro
Caso o fonte não tenha sido decorado com a cobertura veja nos logs do VsCode, aba OUTPUT opção probat, algo
como:
[probat] [coverage] start show ....
[probat] [coverage] [ERROR] arquivo inexistente ou inválido!
[probat] [coverage] end show ....
Nesse exemplo, o arquivo informado na configuração não foi encontrado ou possui formato incorreto.
TOTVSTEC – PROBAT
Informações importantes
Uso somente local

Na versão atual 0.0.2, ainda somente é possível utilizar esse recurso localmente, ou seja, o VsCode e o Appserver
onde é executado devem estar na mesma máquina para que o arquivo gerado esteja ao "alcance" do VsCode.
Está previso para as próximas versões que essa comunicação permita uma arquitetura mais flexível.
BUG
Por vezes, após uso contínuo da visualização em tela da cobertura de código de um ou mais fonte, pode ocasionar
um comportamento inadequado de ao acionar a rotina "Show Coverage" a cobertura em tela ocorrer em linhas
erradas.
Para resolver esse comportamento, basta reiniciar o VsCode e ligar novamente o "Show Coverage".
Já existe um chamado [DTTLPP-2097] para correção desse comportamento.
7.5.6.6 Validação de Cobertura

Além de se obter as linhas de códigos cobertas pelos testes e seus respectivos percentuais de cobertura, podemos
validar se atingimos um percentual mínimo de cobertura, caso contrário, será gerado erro e o resultado dos testes
invalidado.
Para ligar a validação, basta na INI modificar as seguintes chaves:
[PROBAT]
CODECOVERAGE=1
O valor da chave [CODECOVERAGE_PERCENT] deve ser numérico e entre 0 e 100 O valor 0 [zero] significa que a
validação está desativada. Valores acima de zero indicam o percentual mínimo que será aceito para todos os
fontes.
No exemplo acima, definimos que o percentual mínimo de cobertura a ser atingido é de 80%.
Importante saber que esse percentual será usado para validar todos os fontes de seu projeto, porém existem
recursos para que possam tanto modificar o percentual por fonte ou indicar ao PROBAT quais módulos (folders)
serão validados pelo % informado.
Modificando % por fonte

Podem existir casos em que o percentual aplicados para todos os fontes não faça sentido a um ou outro fonte em
específico.
Para isso o PROBAT tem um recurso específico para que possa ser alterado esse percentual por fonte, e iremos
novamente recorrer ao arquivo-fonte de configuração com comando específico, sendo:
COVERAGE PERCENTAGE {%} NAMESPACE {"nome_namespace"} SOURCE {nome_fonte} TYPE {e
xtensao_fonte}
COVERAGE PERCENTAGE {%} SOURCE {nome_fonte} TYPE {extensao_fonte}

O valor passado para o namespace deve estar obrigatoriamente entre aspas.
Exemplo
TOTVSTEC – PROBAT
#include 'tlpp-probat.th'
// Aplica o Percentual em:

// 60%
// para o fonte:
// calculos.tlpp
// Que utiliza o namespace:
// prj.lib
COVERAGE PERCENTAGE 50 NAMESPACE "prj.lib" SOURCE calculos TYPE tlpp
// Aplica o Percentual em:

// 20%
// para o fonte:
// formulas.prw
COVERAGE PERCENTAGE 20 SOURCE formulas TYPE prw
Ao final basta compilar o fonte em seu RPO!
Filtro de módulos
É possível indicar ao PROBAT quais módulos (folder e sub-folders) devem ser validados pelo percentual indicado,
caso não seja informado esse filtro a validação será aplicada a todos os fontes.
Bom, pode parecer um recurso inútil à primeira vista mas imagine um projeto grande de desenvolvimento onde já
existam módulos maduros e que podem ir para a produção ou serem publicados, e ao contrário, módulos ainda em
desenvolvimento e que ainda não estejam alinhados com a qualidade exigida e portanto não faz sentido quebrar
toda uma expedição por módulos ainda em processo de amadurecimento.
Para informar quais módulos devem ser validados, é simples, basta seguir a configuração no INI abaixo:
[PROBAT]
CODECOVERAGE=1
CODECOVERAGE_FILTER_SRC=pasta_1,pasta_2,pasta_3
Os nomes das pastas (módulos) devem ser separadas por vírgula.
No exemplo acima, a validação de cobertura de código somente será aplicada aos fontes que pertençam
hierarquicamente aos diretórios [pasta_1], [,pasta_2] e [pasta_3].
7.5.7 e-7 - Error Log

Podem existir casos onde seu teste cause error.log no sistema, e talvez seja exatamente o esperado.
Mas como então iremos transformar o error.log causado em resultado positivo já que o PROBAT automaticamente
captura os erros catastróficos e gera um resultado negativo no plano de testes?
Para esses casos serão necessários utilizar a annotation [ErrorLog] junto com as annotations [Test] para métodos
ou [TestFixture] para funções.
Ao utilizar esta annotation, deve-se obrigatoriamente informar a descrição do erro, ou seja, o error.log esperado
para que não o teste não falhe.

@TestFixture()
TOTVSTEC – PROBAT
class sample_class_test_errorLog

private data cVar


@Test('causa propositalmente erro de tipo de dados')
@ErrorLog('type mismatch')
public method run1()

endclass

method new class sample_class_test_errorLog
cVar := 'abc'
return self

method run1 class sample_class_test_errorLog
if ( ::cVar == .T. )
endif
return
ou

@TestFixture()
@ErrorLog('type mismatch')
user function sample_function_test_errorLog()
local cVar := 'abc'
if ( cVar == .T. )
endif
return
Neste exemplo, o if falhará pois é realizado a comparação de uma variável do tipo string com um valor booleano.
Porém, como foi utilizado a annotation [ErrorLog] na definição do Teste e com a indicação de "type mismatch", o
resultado do teste será verdadeiro.
Porém, se na definição do erro tivesse qualquer outra descrição que não fosse o error.log causado, mesmo fazendo
uso de [ErrorLog] o resultado será negativo, pois não é exatamente o erro esperado.
Nota: Em caso de não utilização desta annotation, será gerada uma falha no XML com o error log encontrado
durante a execução da thread.
7.5.8 e-8 - Cross Validation

O "Cross Validation" tem a finalidade de dar ao projeto flexibilidade para validar se existem testes escritos para
certos "alvos" conforme necessidade.
O primeiro passo a se fazer é informar ao PROBAT qual a função será responsável pela criação da lista, sendo
assim, faremos da seguinte forma:
Arquivo appserver.ini
TOTVSTEC – PROBAT
[PROBAT]
CROSS_VALIDATION=ListCross
A seguir, devemos criar a função informada no INI seguindo alguns critérios:

• Deve retornar um array simples (vetor);
• Elementos do array devem ser strings;
• Array deve pelo menos ter 1 elemento;
• Função deve estar compilada no mesmo ambiente onde for executar o PROBAT.
Exemplo:
function ListCross()
local aRet := { 'item.1', 'item.2' }
return aRet
Nesse exemplo utilizamos nomes genéricos para deixar claro de que essa lista pode ser referente a qualquer
controle que a equipe de desenvolvimento desejar.
Exemplos de listas:
• Fontes;
• Funções;
• Classes;
• Módulos;
• Recursos;
• Libs;
• etc ...
Ao determinar essa lista, agora seu projeto terá a obrigação de possuir pelo menos 1 teste para cada item.
Caso não exista um teste específico para cada "alvo" da lista, o PROBAT irá gerar erro no processo de apuração de
resultados.
Portanto, agora temos que escrever o teste, porém devemos marcar o teste com seu respectivo "alvo", caso
contrário não haverá como fazer o link entre o "alvo" e o teste.
Para marcar o teste, use a propriedade [target] da annotation [TestFixture], veja:

@TestFixture(target="item.1")
function test_sample_1()
O exemplo acima está "linkando" o teste com o "item.1" da lista. Porém, ainda não temos teste "linkando" com o
"item.2", portanto, caso executarmos o **PROBAT** com esse cenário, teremos um erro registrado.
Logo, após a execução, no processo de apuração do resultado e geração do arquivo de exportação, teremos então
algo como:
TOTVSTEC – PROBAT
<testcase id="1" name="Element:item.1" time="0.000" description="" >

developed test: test dev OK
</testcase>
<testcase id="2" name="Element:item.2" time="0.001" description="" >
<failure type="Warning" message="validation error">
[ER0003] item.2: there is no test developed for this element in cross-validation
</failure>
</testcase>
Para eliminar esse problema nesse exemplo, teremos então que escrever um teste com o [target] para o "item.2".
TOTVSTEC – PROBAT
8 6 - Executando Testes
Após configurar, escrever e compilar os fontes de testes, agora é hora de executá-los.

Por favor, siga a trilha de conhecimento abaixo:
• a - Discovery - Encontrando os Testes no RPO(see page 82)

• b - Modos de execução(see page 83)
• c - Impondo a cobertura de código(see page 86)
• d - Identificador Customizado(see page 87)
8.1 a - Discovery - Encontrando os Testes no RPO

Como dito anteriormente, o PROBAT antes de executar os testes ele precisa encontrá-los e faz isso em seu processo
de configuração pré-execução.
Esse processo de descoberta pode ocorrer em duas situações:
• Quando solicitado.
• Sempre antes da execução dos testes;
Ambos os casos possuem prós e contras, vamos a eles:
Modo Prós Contra
Por Solicitação Garante performance na velocidade É preciso solicitar a descoberta sempre

dos testes. (*1) que houver novos fontes de testes
compilados.
Na Execução Garante a descoberta de fontes recém Em RPO´s grandes, pode-se encontrar

compilados. lentidão a cada execução. (*2)
(*1) Os testes só serão executados se já foi solicitado anteriormente a descoberta.

(*2) - É possível configurar um intervalo de tempo entre cada descoberta, portanto, para execuções efetuadas
dentro desse prazo, realizará somente 1 (um) processo de descoberta, porém nesse intervalo pode-se "perder"
algum fonte novo recém compilado.
É preciso indicar ao PROBAT por qual modo deseja que ele funcione, e para isso é preciso indicar através do INI,
segue:
[PROBAT]
Sendo:
0 - Por Solicitação;
1 - Na Execução.
8.1.1 Por Solicitação

Ao definir por esse modo, teremos que solicitar a descoberta dos fontes quando:
• Primeira execução do motor;
• Quando houver nova compilação de código-fonte de testes.
6 - Executando Testes – 82
TOTVSTEC – PROBAT
Caso fontes sejam compilados e não seja solicitada nova descoberta, o PROBAT sequer saberá da existência desses
testes e portanto não irá executá-los

Para solicitar a descoberta, podemos fazer uso de duas maneiras:
8.1.1.1 1 - Main Function:
tlpp.probat.discovery()
Essa função tem retorno do tipo lógico, sendo:

• .T. conseguiu fazer a descoberta.
• .F. quando ocorrer algum problema.
8.1.1.2 2 - Via api Rest:
/tlpp/probat/discovery
Json Retorno:
{ "sucess": yes|no, "message": "" }
8.1.2 Na Execução
Ao indicar que a descoberta deve sempre ocorrer ao executar, quando solicitado a execução
por tlpp.probat.run() o PROBAT irá sempre procurar por fontes de testes compilados, exceto quando a execução
ocorrer dentro de um intervalo de tempo configurável pela chave abaixo:
[PROBAT]
O Valor deve ser numérico e é em segundos.
8.2 b - Modos de execução

O PROBAT possui uma Main Function exclusiva para a execução dos testes, sendo:
TLPP.PROBAT.RUN()
A função RUN retorna o código de execução de controle interno no formato [character].
Ela permite que você possa enviar através de parâmetros, instruções de modo de execução dos Testes
Abaixo seguem as opções permitidas
TOTVSTEC – PROBAT
8.2.1 Todos testes

Esse modo é útil para executar todos os testes e verificar se após alguma implementação a BUILD permanece 100%
funcional.
tlpp.probat.run('type:all')
ou simplesmente:
tlpp.probat.run()
Ao não passar parâmetro algum, o PROBAT assume automaticamente o type:all
8.2.2 Testes de determinada namespace

Talvez seja necessário executar parcialmente os testes e para isso temos a opção de filtrar a execução através da
namespace usada no fonte de teste.
Seguem alguns exemplos:

Somente uma namespace: string
tlpp.probat.run('type:namespace','string')
Mais de uma namespace: date e math
tlpp.probat.run('type:namespace','date','math')
Namespace longa:
tlpp.probat.run('type:namespace','test.unit.module')
8.2.3 Testes de determinado código-fonte

Poderemos também filtrar a execução através dos fontes de teste.
Esse modo é útil para ser rápida a execução quando estivermos desenvolvendo ou encontrando o erro em
determinado teste.
TOTVSTEC – PROBAT
Somente um fonte: test_maximum.tlpp
tlpp.probat.run('type:source','test_maximum.tlpp')
Mais de um código-fonte: test_maximum.tlpp e test_minimum.tlpp
tlpp.probat.run('type:source','test_maximum.tlpp','test_minimum.tlpp')
8.2.4 Testes com erro

Após a execução de testes em modo ALL, erros podem ocorrer em um ou mais testes e com isso teremos a
necessidade de corrigi-los.
Portanto, temos a opção para executar somente os testes com erro para facilitar o trabalho.
tlpp.probat.run('type:error')
ou
tlpp.probat.run('type:fail')
Esse modo de execução só será possível quando existir no histórico do PROBAT alguma execução em modo ALL e
que possua erros, caso contrário ele não encontrará testes elegíveis para execução.
8.2.5 Testes de Suítes específicas

O PROBAT permite que possam ser criadas SUITES de testes e portanto temos a necessidade de executar somente
os testes que pertençam a determinada SUITE.
Veja mais detalhes em como criar suítes customizadas em: (e-5 - Suítes(see page 69))
Somente uma suíte: sistemico
tlpp.probat.run('type:suite','sistemico')
TOTVSTEC – PROBAT
8.3 c - Impondo a cobertura de código

Nós já vimos o recurso de cobertura de código em [Recursos Avançados] na sessão de Construindo testes.
Aprendemos que para ativar existem chaves de configuração no INI do appserver.
Porém há uma forma de ativar e desativar a Cobertura de Código independentemente da chave o INI em tempo de
execução dos testes.
E como podemos fazer isso?
8.3.1 Ligando Coverage

Podemos ligar por algumas formas:
// Utilizando Main Function:

tlpp.probat.runOnCoverage()

// Primeiro parâmetro lógico e .T.
tlpp.probat.run(.T.)

// Parâmetro nomeado
tlpp.probat.run('coverage:on')
8.3.2 Desligando Coverage

Podemos desligar por algumas formas:
// Utilizando Main Function:

tlpp.probat.runOffCoverage()

// Primeiro parâmetro lógico e .F.
tlpp.probat.run(.F.)

// Parâmetro nomeado
tlpp.probat.run('coverage:off')
8.3.2.1 Importante:
Vale ressaltar que os modos apresentados acima terão prioridade sobre a configuração do INI, ou seja, se no INI
estiver ligado o coverage, porém usaram 'coverage:off' no parâmetro da RUN, o Coverage será desligado em tempo
de execução e a chave INI será ignorada.
TOTVSTEC – PROBAT
8.4 d - Identificador Customizado

O PROBAT permite que na execução dos testes um identificador customizado possa ser enviado através da função
RUN, assim esse identificar ficará gravado na tabela [PROBAT_TEST_EXECUTION] e no campo [CUSTOM].
O campo [CUSTOM] é do tipo "character" e de tamanho 255 posições.
Esse recurso é interessante pois ele flexibiliza a forma de identificar diferentes execuções dos testes.
Por exemplo, em um cenário onde existem múltiplas execuções de testes, tais como: unitários, integrados e
funcionais, todos são executados em momentos distintos e portanto terão códigos de execução diferentes, esse
recurso possibilita agrupá-los pois todos eles irão possuir o mesmo Identificador Customizado, dessa forma os
resultados serão agrupados em uma única exportação.
Para enviar um identificador customizado, execute a função RUN da seguinte forma:
tlpp.probat.run('custom:123456789')
// ou
tlpp.probat.run('param:123456789')
// Ambas as opções farão o PROBAT gravar 123456789 no campo CUSTOM

Saiba mais em:
• Modos de execução de testes(see page 82)
• Exportação de arquivos(see page 88)
TOTVSTEC – PROBAT
9 7 - Analisando Resultados
O PROBAT possui algumas formas para se obter os resultados dos testes, abaixo veremos cada um de forma
detalhada.
• a - Exportando Resultados(see page 88)

• b - tlpp.probat.export()(see page 90)
• c - Warning(see page 91)
• d - SQLite(see page 91)
9.1 a - Exportando Resultados

Ao final da execução o PROBAT pode exportar o resultado dos testes automaticamente, conforme possível
configurar através do appserver.ini em sessão específica.
[PROBAT]
EXPORT_AFTER_RUN=1
EXPORT_FILE_NAME=results
EXPORT_FORMAT=JUnit
9.1.1 EXPORT_AFTER_RUN
Indica se ao final da execução gera o resultado automaticamente ou não, sendo:
0 = Não gera arquivo.
1 = Gera arquivo com resultado, baseado em EXPORT_FILE_NAME e EXPORT_FORMAT.
Caso opte pela geração automática, o arquivo será gerado na pasta ROOT/SYSTEM do appserver com o nome
definido em [EXPORT_FILE_NAME] e com o formato definido em [EXPORT_FORMAT].
Quando exportado logo após a execução dos testes serão exportados apenas os resultados da última execução dos
Testes.
Porém, caso a escolha opte por não gerar automaticamente, para gerar a exportação é preciso utilizar a Main
Function:
tlpp.probat.export()
Veja mais sobre esse recurso em: ( export()(see page 90) )
9.1.2 EXPORT_FORMAT
Até o momento temos somente implementado o formato jUnit, portanto a chave precisa ser:
[EXPORT_FORMAT=JUnit]
Portanto ao exportar o arquivo, o arquivo XML gerado será no formato jUnit e seu conteúdo será parecido com:
<?xml version="1.0"?>
<testsuites id="20190109203113" name="results" type="all" tests="1" skipped="0"
7 - Analisando Resultados – 88
TOTVSTEC – PROBAT
failures="0" time="0.002" >

<testsuite id="000001" name="all" tests="1" skipped="0" failures="0" time="0

.002" >
<testcase id="1" name="Class:MANUALUT.TEST_MANUALUT():New() |
Method:EXAMPLEFORUSE()" time="0.002" >
Folder: TEST/UNIT/MANUALUT | Call: U_manualUT( cTest ) | Expected: {C}-
[test_1] | Result: {C}-[test_1]
</testcase>
</testsuite>
</testsuites>
9.1.3 EXPORT_FILE_NAME
O nome do arquivo pode ser customizado, basta informar o nome desejado por uma chave do INI de seu appserver.
Exemplo 1:
[TLPP_ENGINE_TESTS]
FILE_NAME_EXPORT=
Irá manter o nome padrão da engine, ou seja, "results" para resultados e "coverage" para cobertura de código.
Ficando:
results.xml -> Resultados em formato jUnit
coverage.json -> Json de cobertura de código para uso no VsCode
coverage.xml -> XML com dados da cobertura de código
Exemplo 2:
[TLPP_ENGINE_TESTS]
FILE_NAME_EXPORT=customname
Gerará então:
customname.xml -> Resultados em formato jUnit
customname.json -> Json de cobertura de código para uso no VsCode
customname (1).xml -> XML com dados da cobertura de código
Note que dessa forma, existirá conflitos com arquivos com a mesma extensão e exigirá uma experiência maior do
operador para saber a finalidade de cada arquivo.
Por essa razão, sugerimos utilizar um dos dois modos a seguir.
Exemplo 3:
[TLPP_ENGINE_TESTS]
FILE_NAME_EXPORT=*customname
Gerará então:
TOTVSTEC – PROBAT
unit-customname.xml
coverage-customname.json
coverage-customname.xml
Exemplo 4:
[TLPP_ENGINE_TESTS]
FILE_NAME_EXPORT=customname*
Gerará então:
customname-unit.xml
customname-coverage.json
customname-coverage.xml
9.2 b - tlpp.probat.export()
É possível solicitar a exportação sempre que desejar, e para isso é preciso fazer uso da Main Function:
tlpp.probat.export()
Como parâmetro, devemos informar o tipo de códigos para busca das execuções e claro, a lista de códigos
desejados:
Os tipos disponíveis para uso são:
Tipo Como informar Descrição
code "type:code" Código de execução dos testes (*1)
custom "type:custom" Identificador customizado enviado para a execução

(*2)
(*1) - Para obter um código de execução, utilize o retorno das funções RUN do PROBAT.
(*2) - Veja informações detalhadas em: (Identificador Customizado)
Exemplos:
tlpp.probat.export( "type:code", "20211217155201" )

// ou

tlpp.probat.export( "type:custom", "Hgk34Gnm90" )
Pode-se enviar mais de um código para unificar os resultados no momento da exportação.
TOTVSTEC – PROBAT
9.3 c - Warning
Ao utilizar o tlpp.probat.assertWarning(), o motor registrará a mensagem de aviso solicitada porém não irá gerar
resultado, nem positivo e nem negativo.
Exemplo:
tlpp.probat.assertWarning( 'Desc: Gera mensagem de aviso, mas nao gera resultados nem positivo, nem
negativo' )
Os avisos serão registrados na tabela [PROBAT_TEST_WARNING].

No momento da exportação dos resultados, quando houver mensagens de avisos registradas, será gerado um
arquivo XML apartado do arquivo dos resultados.
O nome do arquivo deverá manter o padrão:
{nome_arquivo_definido}_warning.xml
Seu conteúdo deverá ser parecido com:
<?xml version="1.0"?>
<warnings name="tlppCore_tests_warning" date="12/17/21" time="13:52:01" >
<exec code="20211217135200" >
<warning id="1" call_source="TEST_SAMPLE_ASSERTS.TLPP" call_line="30" >
Desc: Gera mensagem de aviso, mas nao gera resultados nem positivo, nem negativo
</warning>
</exec>
</warnings>
Veja o exemplo completo no GitHub.
9.4 d - SQLite
Todas as execuções de testes são armazenados em um SQLite, dessa forma, é possível comparar e consultar
resultados antigos caso seja necessário alguma análise retroativa.
Vamos à tabelas disponíveis com dados dos resultados:
9.4.1 Testes
TOTVSTEC – PROBAT
9.4.1.1 [PROBAT_TEST_EXECUTION]
Tabela principal da execução dos testes contendo dados principais.
CODE_EXEC C Código de Execução
DATE D Data da Execução
TIME C Hora da Execução
START C Time Início dos Testes (suites)
FINISH C Time Fim dos Testes (suites)
CALLSTACK C Main Function de entrada ao PROBAT utilizada para

solicitar a execução
TYPE C "Type" informado nos parâmetros
PARAMS C Parâmetros passados para main function de entrada
CUSTOM C Identificador customizado
9.4.1.2 [PROBAT_TEST_RESULTS]
Resultados totalizados entre todos os testes, agrupados conforme parâmetros enviados à função de entrada.
CODE C Código de controle interno
CODE_EXEC C Código execução
TYPE C Agrupamento dos types enviados nos

parâmetros
START C Time Inicio dos Testes (grupos)
FINISH C Time Fim dos Testes (grupos)
TOTVSTEC – PROBAT
TOTAL N Total de Testes registrados
OK N Qtde de Testes com Sucesso
ERROR N Qtde de Testes com Erro
NOTEXECUTE N Qtde de Testes Pulados "Skip"
9.4.1.3 [PROBAT_TEST_TESTS]
Resultado de cada registro de teste, gerado por cada assert executado.
CODE C Código controle Interno
START C Time Início Teste
FINISH C Time Fim Teste
RESULT_FROM C Indica quem é o gerador dessa linha de testes ( T

= Test
CODE_ROUTINE N Código da rotina de teste (cadastro interno)
TYPE_ROUTINE C Tipo da Rotina que gerou resultado ( TST = Teste
ANNOTATION M Descrição capturada pela annotation
ROUTINE C Nome Fonte
FOLDER C Diretório do fonte
TYPE C Tipo rotina ( C = Class
NAMEFUNCTION C Nome da Function
NAMECLASS C Nome da Class
TOTVSTEC – PROBAT
NAMEMETHOD C Nome do Method
SEQUENCE C Sequencia do assert dentro do mesma função/

método
TARGET C Rotina algo do teste
ERROR M Mensagem de erro, quando houver
DESCRIPTION M Descrição enviada pelo assert
SOURCE_CALL C Fonte que chamou o assert
LINE_CALL N Linha do fonte onde chamou o assert
ASSERT C Função de Assert Usada
RESULT C Resultado gerado pelo teste
EXPECTED C Valor esperado para o teste
OK N Resultado ( 0 = Erro
9.4.1.4 [PROBAT_TEST_ERRORS]
Tabela contendo todas as mensagems de erros capturas pelo PROBAT
CODE_SRC N Código cadastro de fontes do projeto
CODE_TST N Código cadastro do fonte de teste
NAMESPACE C Namespace usada no fonte
SOURCE C Fonte
TOTVSTEC – PROBAT
CODE C Código erro
ERROR M Mensagem de erro
9.4.1.5 [PROBAT_TEST_WARNING]
Tabela contendo todas as mensagens de aviso geradas pelo assertWarning().
CODE_EXEC C Código de execução
WARNING C Mensagem de aviso
SOURCE_CALL C Fonte que executou o assert
LINE_CALL N Linha do fonte que executou o assert
9.4.2 Cobertura de Códigos

Dados relacionados à cobertura de código
9.4.2.1 [PROBAT_CODECOVERAGE_TOTAL]
Percentual Total de cobertura sumarizado por todos os fontes
SOURCES N Qtde de fontes apurados
LINES N Qtde de linhas apuradas
COVERAGE N % total de cobertura ( todos os fontes )
TOTVSTEC – PROBAT
COVERAGE_FRAME N % total de cobertura de fontes oficiais do

projeto
COVERAGE_TEST N % total de cobertura dos fontes de testes
9.4.2.2 [PROBAT_CODECOVERAGE_SOURCES]
Percentual Total de cobertura por fonte
RUN C Indica se esse fonte foi executado ( 0 = Não
SOURCE C Nome fonte
LINES N Qtde linhas do fontes
COVERAGE N % cobertura de código para esse fonte
9.4.2.3 [PROBAT_CODECOVERAGE_LINES]
Informação linha a linha por fonte sobre a cobertura
SOURCE C Nome fonte
LINE C Número da linha do fonte
Campo
CHANGE
COVERAGE
C
N
Tipo Dado
Descrição
Debugável
Indica que houve troca entre -1 e 0

Informação de cobertura da linha ( -1 = Não
TOTVSTEC – PROBAT
TOTVSTEC – PROBAT
10 8 - Como tudo acontece

O PROBAT procura no RPO por classes e funções que utilizam por determinadas annotations para a execução dos
testes.
No exemplo usado com a implementação básica de um teste com classe, tivemos a utilização de duas annotations,
são elas:
[TestFixture]
[Test]
Abaixo vamos resumir como a mágica acontece!
Portanto, detalharemos através dos passos de A a G.
10.1 [A]
Veja o trecho de nosso exemplo:

@TestFixture()
class test_sample
A annotation [TestFixture] serve para marcar a classe ou função como um

dispositivo de teste.
Somente através dessa marcação é que o PROBAT consegue descobrir quais são as classes ou funções específicas
de testes.
Um ponto importante é que para fazer uso da annotation referida é preciso importar a include exclusiva
do PROBAT fazendo a inserção da instrução logo no começo do fonte: [#include "tlpp-probat.th15"]
10.2 [B]
Veja esse outro trecho do mesmo exemplo:
@Test('Sample test for the engine manual.')

public method sampleTest()
Nesse trecho do código, marcamos o método sampleTest() como um método a ser

executado durante os testes através da annotation [Test].
Importante ressaltar que a descrição do teste, feito através do primeiro parâmetro da annotation, é obrigatório
pois ele passará por uma função que faz essa validação.
NOTA: Se você declarar uma classe com [TestFixture] e não tiver nenhum método com annotation [Test], seu teste
começará a ser executado, porém gerará um resultado do tipo SKIPPED.
15 http://tlpp-probat.th/
8 - Como tudo acontece – 98

TOTVSTEC – PROBAT
10.3 [C]
Outro ponto importante para a correta configuração, é utilizar o recurso de namespace.
Veja o trecho:
namespace test.unit.sample
Em nosso exemplo, utilizamos o nome do diretório onde se localiza a

implementação do teste, ou seja, test/unit/sample.
Essa informação é importante para fácil localização física dos fontes de testes, afinal ele estará identificado como
FOLDER, tando na gravação do SQLite como no XML gerado.
Exemplo:
<testcase id="1" name="Class:TEST.UNIT.SAMPLE.TEST_SAMPLE():New() | Method:SAMPLETEST()" time="0.002"

description="Sample test for the engine manual." >
Folder: TEST/UNIT/SAMPLE/ | Description: U_SAMPLE( cTest ) | Assert: TLPP.PROBAT.ASSERTEQUALS | Call
From: TEST_SAMPLE.TLPP:57 | Expected: {C}-[test_1] | Result: {C}-[test_1]
</testcase>
Outro modo de informar o FOLDER é através da propriedade da annotation, segue:
@Test('Sample test for the engine manual.',folder='test/unit/sample')

public method sampleTest()
Nesse caso, o PROBAT irá priorizar o valor informado pela annotation.
10.4 [D]
Uma obrigatoriedade é o uso de duas includes, são elas:
• A include [tlpp-core.th] só é obrigada nesse exemplo pois escrevemos o teste com classe, pois caso
tivéssemos criado o teste com função não precisaríamos.
• A obrigatoriedade da include [tlpp-probat.th] será para todos os testes, pois é nela que se encontram as
definições das annotations, comandos e instruções usadas pelo PROBAT.

TOTVSTEC – PROBAT
10.5 [E]
Por último e não menos importante, para que o teste seja registrado pela PROBAT na execução é preciso fazer uso
de alguma função assert() dentro do método ou função de teste, veja o trecho:
assertEquals( ::xValue, ::xExpected, 'U_SAMPLE( cTest )' )
Porém, para que o assert funcione corretamente, é preciso realizar o "import" do namespace da PROBAT em seu
fonte de teste, pois essa função é de uso exclusivo do tlppCore.
Ou simplesmente utilizar o namespace diretamente na chamada da função:
tlpp.probat.assertEquals( ::xValue, ::xExpected, 'U_SAMPLE( cTest )' )
Em nosso exemplo, utilizamos a função assertEquals() pois faz a comparação entre

dois valores que devem ser iguais.
Para saber mais em detalhes sobre as funções de asserts disponíveis, acesse o link abaixo!
• PROBAT - asserts(see page 30)
Após seguir todos os passos acima, basta compilar seu código-fonte de teste para que seja possível executá-lo.
10.6 [F]
Para executar seus testes, basta fazer uso da Main Function disponibilizada pelo PROBAT, assim pode-se executá-
la:
• Através de algum código-fonte;
• Diretamente pela execução do VsCode;
• Linha de comando do Sistema Operacional através do appserver.
Exemplos:

TOTVSTEC – PROBAT
10.6.1 1 - Código fonte
user function MeusTestes()

tlpp.probat.run()

return
10.6.2 2 - VsCode
Ao pressionar Crtl + F5 ou F5 em seu VsCode, informe o seguinte na caixa de diálogo aberta:
tlpp.probat.run
10.6.3 3 - Linha de comando

Windows
• abra o prompt de comando DOS.
• acesse o diretório onde se encontra o appserver.
• depois utilize o comando:
appserver.exe -console -consolelog -run=tlpp.probat.run -env=NOME_AMBIENTE
10.7 [G]
Resumidamente o PROBAT irá obter as funções ou classes de testes através das annotations:
• TestFixture
• Test
Grava as funções no SQLite para uso posterior ou logo em seguida, dependendo do modo escolhido de "discovery".
Ao executar, lê os nomes de funções e classes já descobertos e executa todos os testes que estejam dentro do
escopo pedido pela função RUN.
Através das funções de asserts existentes dentro dos fontes de testes, faz as comparações devidas conforme o valor
produzido pelo teste e o valor esperado e após grava no SQLite o resultado dessa operação.
Ao final, faz a exportação dos resultados em um arquivo no formato pedido.

TOTVSTEC – PROBAT
11 9 - Exemplo no GitHub
Disponibilizamos no GitHub da TOTVS um projeto com exemplos práticos e simples para facilitar o entendimento
sobre o PROBAT.
Sinta-se à vontade de baixar os fontes em:
https://github.com/totvs/tlpp-probat-samples.git
9 - Exemplo no GitHub – 102

PROBAT v6 20220708 - 215928

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PROBAT v6 20220708 - 215928

Enviado por

Direitos autorais:

Formatos disponíveis

You are using an UNLICENSED copy of Scroll PDF Exporter for Confluence.

Exported on 07/08/2022

6 4 - Primeiros Passos ..........................................................................................24

7.1 a - Teste simples com função ................................................................................................ 26

7.2 b - Teste simples com classe ................................................................................................. 27

7.4.5.3 Retorno ................................................................................................................................................................. 37

7.4.10.3 Retorno ................................................................................................................................................................. 44

7.4.15.3 Retorno ................................................................................................................................................................. 52

7.5.1.8 TARGET ................................................................................................................................................................. 61

7.5.1.9 - RUNWITHALL | RWA............................................................................................................................................ 62

8 6 - Executando Testes .......................................................................................82

8.2.5 Testes de Suítes específicas ................................................................................................................................ 85

8.3 c - Impondo a cobertura de código ....................................................................................... 86

10 8 - Como tudo acontece....................................................................................98

10.6.3 3 - Linha de comando......................................................................................................................................... 101

10.7 [G].......................................................................................................................................... 101

1 Motor de Testes tlppCore

Motor de Testes tlppCore – 10

Veja os passos a seguir:

 tlppCore version 01.03.00

 tlppCore version 01.03.00

 tlppCore version 01.03.00

appserver.exe -compile -applypatch -files=D:\totvs\patch\probat_Harpia.ptm -env=a

4.4 a - Verificando a instalação

conout( ' >> Ferramenta não instalada <<' )

Saiba mais sobre esse recurso em:

Todas as chaves de configuração serão descritas nas páginas seguintes.

• a - Arquitetura de diretórios do projeto(see page 16)

5.1 a - Arquitetura de diretórios do projeto

5.1.1 Fontes Oficiais Projeto >> /src/

5.1.2 Testes >> /test/

5.1.2.1 Módulos / Funcionalidades

5.2 b - Encontrando fontes oficiais

5.2.1 Hierarquia de diretórios

5.2.3 Tabela SQLite

Campo Tipo Dado Descrição

CODE N Código do fonte oficial (uso interno)

FOLDER C Folder de localização do fonte

SOURCE C Nome do arquivo fonte

NAMESPACE C Namespace usada no fonte

5.3.1 Exemplo: appserver.ini

5.3.2 Descrição das chaves

5.3.2.4 CODE COVERAGE

6.1 1 - Criando código-fonte teste

tlpp.probat.assertEquals( cValue, 'N' )

Elementos exclusivos do PROBAT

6.2 2 - Executando Testes

linha de comando do appserver.

Exemplo de Linha de comando:

appserver.exe -console -consolelog -run=tlpp.probat.run -env={NOME_AMBIENTE}

Função Link TDN

Para seguir com a implementação é preciso ter os seguintes conhecimentos prévios:

7.1 a - Teste simples com função

using namespace tlpp.probat

local nInt_1 as integer

return .T. // NOTA: Sempre retornar TRUE

7.2 b - Teste simples com classe

using namespace tlpp.probat

private data nInt_1 as integer

public method new() constructor

@Test('aqui deve-se colocar o descritivo sobre o teste')

method new() class test_max_class