Se você trabalha ou já trabalhou em um grande projeto com uma alta cobertura de testes, com certeza você já passou raiva na hora de executar os testes da aplicação localmente.
Isso por que, quanto maior o projeto e mais bem coberto por testes, maior o tempo para executar todas as validações.
Pois bem, hoje venho te mostrar duas formas de continuar com uma ótima cobertura de testes, porém economizar um bom tempo na hora de executá-los localmente ou na abertura de PRs.
Leia mais »
Alguns meses atrás, eu estava escrevendo uma aplicação. Quando fui escrever os testes do meu repositório, fiquei incomodado em ficar copiando e colando parte do código para gerar uma nova instância do repositório para cada ação do CRUD que eu queria testar. Foi então que, procurando na documentação do testify, descobri sobre o package suite.
Se você nunca utilizou o testify, recomendo que leia primeiro o nosso post “Como escrever testes com testify”.
Nesse post, vou mostrar como podemos escrever testes unitários utilizando o package testify suite e sqlmock.
Para que o post não fique muito extenso, ao invés de implementar o repositório também, vamos só imaginar que ele tem os métodos Insert, Update, Delete e FindByID implementados.
Para começar, precisamos criar uma struct que faça o embed da struct suite.Suite. Esse embed é obrigatório. Todos os outros campos não são obrigatórios. São apenas uma forma de facilitar a nossa vida na hora da escrita dos testes.
type RepositorySuite struct {
suite.Suite
conn *sql.DB
DB *gorm.DB
mock sqlmock.Sqlmock
repo *repository
person *Person
}
Leia mais » 
Na primeira parte desse post, vimos como utilizar o fuzz test para gerar payloads automaticamente em nossos testes, o que nos ajudou a encontrar problemas quando o payload não vinha no formato que esperávamos.
Nessa segunda parte, vamos utilizar o fuzz para gerar os inputs que serão utilizados nos campos de um payload correto.
Utilizando o mesmo código do post anterior, antes de começar, vamos fazer uma pequena mudança na validação de e-mail. Além de validar se ele foi preenchido, vamos validar se o e-mail é válido.
Para isso, vamos criar um novo erro e um else para quando o valor do e-mail não esteja vazio.
...
ErrEmailRequired = errors.New("Email is required")
ErrEmailInvalid = errors.New("Email is invalid")
...
if p.Email == "" {
return ErrEmailRequired
} else {
rgx := regexp.MustCompile("^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:.[a-zA-Z0-9-]+)*$")
if !rgx.MatchString(p.Email) {
return ErrEmailInvalid
}
}
...
Leia mais » 
Na edição de 2022 da GopherCon Brasil, tive o prazer de palestrar sobre Fuzz Test. Foi muito bacana, pois durante a palestra, assim como nos corredores do evento, fizeram vários questionamentos que eu ainda não tinha feito sobre essa feature do Go.
Se você ainda não conhece esse tipo de teste, convido você a ler um post que publicamos aqui no blog (link para o post) onde explicamos melhor o assunto.
O que vou tratar nesse post é o resultado das perguntas feitas no evento mais um link que o Ricardo Maricato me enviou.
Para ver uma das formas de implementar o Fuzz Test para requests HTTP, vamos implementar um endpoint para validação dos dados de uma pessoa.
Vamos começar criando uma struct com um método de validação, e algumas variáveis para armazenar os erros de validação que podemos ter.
Leia mais »