Built-In Contract Testing

João dos Prazeres

Motivação

• Novo desafio na Engenharia de Software: Reuso

• Componentes é uma abordagem para facilitar reuso

• Mas há o problema de integração dos componentes

• Built-In Contract Testing:

– Testes embutidos nos componentes clientes e servidores

– Testam os contratos entre os componentes

BICT

• Testing Profile aborda apenas black-box conformance test

• SUT (system under test) só interfaces funcionais

• BICT requer interfaces que mostre o estado interno.

• Baseado nas relações cliente/servidor aplicada ao nível de componentes.

• O componente cliente contém um sub-componente testador

• Testa as interfaces do servidor antes que a interação entre eles se inicie.

Artefatos de BICTServer Tester

Artefatos de BICT

Context

<<component>>Client

<<component>>Server

<<acquires>>

<<creates>>

<<component>>Server Tester

<<acquires>>

Context

<<component>>Client

<<component>>Server

<<acquires>>

<<creates>>

Server Tester

• Server Tester (subcomponente do cliente) se utiliza da interface Server, que passa a se chamar Testable Server.

• Esta abordagem também é utilizada para modelar BICT a componentes de terceiros.

Artefatos de BICTServer Tester – 1 abordagem

<<component>>Testable ServerPublic interface

<<component>>Testing Client

Server Tester

• O Testable Server (antigo Server Component) disponibiliza um conjunto de interfaces que expõe seus estados internos para facilitar testes – Testing Interfaces

Artefatos de BICTServer Tester – 2 abordagem

<<component>>Testable ServerPublic

interface

Testing interface

<<component>>Testing Client

Server Tester

• Há três maneiras para a implementação das interfaces de teste:

1. A primeira trata de implementa-la criando vários métodos para determinar e verificar cada estado.

2. A segunda, cria atributos para cada estado, e cria apenas dois métodos genéricos para determinar e verificar o estado, passando-o como parâmetro.

3. A terceira abordagem cria um componente que herda do componente a ser testado, e neste utiliza a segunda abordagem.

Artefatos de BICTServer Tester

• Testing Interface – Formas de Implementar Testing Interfaces

Artefatos de BICT

<<component>>Testable ServerPublic

interface

Testing interface

Perguntas?!?

Transparências

Complementares

SPEM – Software Process Engineering MetaModel

• A modelagem é feita através do uso de estereótipos• Os principais estereótipos definidos pelo SPEM são:

– WorkProduct– WorkDefinition– ProcessPerformer– ProcessRole– ProcessPackage– Phase– Process– Document– UMLModel– Activity– Guidance

SPEM – Software Process Engineering MetaModel

• WorkProduct: classe de produto de trabalho produzido em um processo e está associado a um tipo de produto. Ex: documento, código fonte, etc. Artefato

• Notação:

• WorkDefinition: é um tipo de operação que descreve o trabalho realizado no processo. É a representação para atividades compostas por outras sub-atividades.

• Notação:

SPEM – Software Process Engineering MetaModel

• ProcessPerformer: define o “realizador” de um conjunto de WorkDefinitions do processo.

• Notação:

• ProcessRole: define responsabilidades em relação a WorkProducts específicos e define papéis que realizam e auxiliam atividades específicas.

• Notação:

SPEM – Software Process Engineering MetaModel

• ProcessPackage: notação especial para pacotes no contexto SPEM

• Notação:

• Phase: é uma especialização de um WorkDefinition em que sua pré-condição define a fase de critérios de entrada e seus objetivos definem a fase de critérios de saída

• Notação:

SPEM – Software Process Engineering MetaModel

• Process: representa um processo completo, em toda

sua extensão.

• Notação:

• Document: notação específica para diferentes tipos de WorkProducts

• Notação:

SPEM – Software Process Engineering MetaModel

• UMLModel: notação específica para diferentes tipos de WorkProducts

• Notação:

• Activity: descreve uma parte do trabalho realizado por um ProcessRole: suas tarefas, operações e ações executadas por um papel ou de que forma o papel deve auxiliar

• Notação:

SPEM – Software Process Engineering MetaModel

• Guidance: Informação mais detalhada sobre o elemento associado fornecida aos praticantes Ex:Guidelines, Metrics, Tools, Checklists e Templates.

• Notação:

Unified ProcessOPEN

«uses»

KobrA

PuLSE

«uses»

Catalysis

Cleanroom

SELECT Perspective

«uses»

BICT

«uses»«extends»

«uses»«uses»

BICT Reuse

Step 1 - Identification of Tested Interactions

Identify removable built in testing

Identify pernament built in testing

Identify client-servership interaction

Identified associations in component diagram

Software engineerComponent diagram

[updated]

Este passo trata de analisar se os elementos de BICT devem ficar permanentes num contexto ou se devem ser removidos após a integração dos componentes e como identificar as interações testáveis.

Step 2 – Definition and Modeling of the Testing Architecture

Software engineer

Component Diagram

Add Tester Components

Component diagram with new associations

Provide Testing Interface in the servers

Testing Component Architecture

Component diagram with Testable Komponents

Replace Server by Testable Komponents

Este passo é a explicitação de como estender o modelo do sistema para considerar elementos do modelo de contract testing. Os elementos do modelo que pertencem a testes devem ser indicados com o estereótipo <<Testing ...>>.

Step 3 – Specification of the Testing Interfaces for the identified

associations

Software engineer[no more operations to be

specified]

[has operation to be specified]

Specify functional specification of the

operation

Operation funcional especificationFusion method template Component diagram

[updated]

Add setting and checking state operations to

Testable Komponent

Testable Komponent protocol state machine

diagram

Create Testable Komponent behavioral

model

Como entrada é necessário uma especificação funcional completa das operações do servidor (como previsto no método Kobra). A especificação funcional é informação suficiente para definir as operações de verificação e determinação do estado do componente, as quais constituem as interfaces de teste.

Step 4 – Realization of the Testing Interfaces

Software engineer

Realize Testable Komponent

Testable Komponent class diagram with OCL

Testable Komponent communication diagram

Testable Komponent activity diagram

Este passo trata da realização da interface de testes para o papel servidor de uma associação. A realização das interfaces de teste dependem diretamente da realização do componente servidor a qual ela pertence.

Step 5 – Tester Component Specification

Software engineer

Define Quality Assurance Plan

Test case selection techniques

Select test case tequiniques

Test cases

Quality assurance plan

Quality Engineer

Specify Tester Komponent

Komponent protocol state machine diagram

Tester Komponent component diagram

Testable Komponent realization model

Os componentes testadores são identificados e desenvolvidos na especicificação do componente cliente (Testing Component). Os casos de teste são derivados de acordo com a realização do modelo comportamental do componente cliente que o contém.

Step 6 – Realization of the Tester Component

Software engineerRealize Tester Komponent

Test cases

Source code

{OR}

Tester Komponent class diagram with OCL

Tester Komponent communication diagram

Tester Komponent activity diagram

A realização de um componente testador está relacionado a como um o componente será organizado e implementado e que testes ele conterá. Eles podem conter sub-componentes testadores ou que auxiliam nos testes.

Step 7 – Integration of the Components

Software engineer

Define client wrapper

Define server wrapper

Create adaptor

or

or

Implement client wrapper

Implement server wrapper Running System

Este passo trata de definir adaptadores ou wrapers entre os clientes e servidores que já possuem artefatos de BICT. Trata também da criação de stubs para a execução de testes. Tais stubs, seguindo os conceitos de Testing Profile, teriam o estereótipo <<Test Component>>.