| package br.com.zup.edu.nossocartao.propostas.cards.jobs; | |
| import br.com.zup.edu.nossocartao.propostas.cards.CardRepository; | |
| import br.com.zup.edu.nossocartao.propostas.cards.integration.CardsClient; | |
| import br.com.zup.edu.nossocartao.propostas.cards.integration.FindCardByProposalIdResponse; | |
| import br.com.zup.edu.nossocartao.propostas.cards.model.Card; | |
| import br.com.zup.edu.nossocartao.propostas.proposals.ProposalRepository; | |
| import br.com.zup.edu.nossocartao.propostas.proposals.model.Proposal; | |
| import br.com.zup.edu.nossocartao.propostas.proposals.model.ProposalStatus; | |
| import org.springframework.beans.factory.annotation.Autowired; |
| package br.com.zup.edu.pix | |
| import java.lang.IllegalStateException | |
| /** | |
| * Representa todas as instituições financeiras passíveis de trabalhar com Pix | |
| * https://www.bcb.gov.br/pom/spb/estatistica/port/ASTR003.pdf (line 229 - 60701190 ITAÚ UNIBANCO S.A) | |
| */ | |
| class Instituicoes { |
Para escrever os testes de integração dos endpoints gRPC eu tive basicamente que levantar o contexto do Micronaut (com @MicronautTest) juntamente com um banco H2 em vez do PostgreSQL pois meu schema é MUITO simples e não valeria o custo de levantar um PostgreSQL via TestContainers. Por haver muita integração com os serviços satélites ITAU-ERP e BCB, eu mockei ambos.
No fim, eu segui duas abordagem na hora de escrever os cenários de testes:
- Para o endpoint
RegistraChaveEndpoint, eu adentrei sua classe Service para extrair os cenários de testes, ou seja, todos os cenários foram concebidos a partir das classes de Endpoint + Service. No fim, escrevi uma única classe com todos os testes: [RegistraChaveEndpointTest](https://github.com/zup-academy/orange-stack-pix-keymanager-grpc/blob/master/src/test/kotlin/br/com/zup/edu/pix/registra/RegistraChaveEndpoin
| // Bean Validations = spec = PDF -> Hibernate-Validator -> JAR | |
| @Intropected | |
| data class ProdutoRequest( | |
| @field:NotNull val codigo: Int, // obrigatorio | |
| @field:NotBlank @field:Size(max=42) val nome: String // obrigatorio e tamanho maximo de 42 | |
| ) | |
- Integrantes: Yuri Matheus e Rafael Ponte (eu)
- treinamento com 4 modulos
- Divisao dos modulos para 1a sprint
- 2 primeiros modulos para o release do treinamento
- Yuri ficou com modulo de JVM
- Rafael ficou com modulo de Persistencia
| var auth_username = pm.variables.get("auth_username") | |
| var auth_password = pm.variables.get("auth_password") | |
| var client_id = pm.variables.get("client_id") | |
| var client_secret = pm.variables.get("client_secret") | |
| var authBody = `username=${auth_username}&password=${auth_password}&grant_type=password&client_id=${client_id}&client_secret=${client_secret}`; | |
| console.log(authBody) | |
| var force_refresh = true | |
| var token_expires_in = pm.environment.get("token_expires_in"); | |
| var token_created = pm.environment.get("token_created"); |
| hooks: | |
| - type: edit-xml | |
| trigger: after-render | |
| path: pom.xml | |
| encoding: UTF-8 | |
| namespaces: | |
| - name: ns | |
| value: "http://maven.apache.org/POM/4.0.0" | |
| - name: xsi | |
| value: "http://www.w3.org/2001/XMLSchema-instance" |
| import org.slf4j.LoggerFactory | |
| import org.springframework.jdbc.core.JdbcTemplate | |
| import org.springframework.stereotype.Component | |
| import org.springframework.transaction.annotation.Propagation | |
| import org.springframework.transaction.annotation.Transactional | |
| import java.time.Duration | |
| interface LockManager { | |
| fun <T> tryWithLock(key: Long, timeout: Duration, function: () -> T): T | |
| } |
Perf
Teste carga signigica verificar como uma aplicação ou sistema se comporta sob uma determinada carga de trabalho (workload) esperada, que pode ser uma carga pequena, moderada ou grande. Além disso, essa carga é aplicada durante algum intervalo de tempo, como minutos ou horas, para validar a estabilidade do sistema e detectar possíveis problemas no uso de recursos, como memória, CPU, disco ou conexões com um banco de dados por exemplo. É importante entender que um teste de carga não ultrapassa a capacidade esperada ou projetada para uma aplicação ou sistema.
Enquanto teste de estresse está relacionado a verificar como uma aplicação ou sistema se comporta quando aplicamos uma carga de trabalho (workload) muito alta e intensa, geralmente uma carga superior a esperada ou especificada nos requisitos. A ideia aqui é submeter a aplicação além da sua capacidade projetada a fim de detectar problemas ou gargalos no uso de recursos ou componentes internos. O