Alura > Cursos de Mobile > Cursos de React Native > Conteúdos de React Native > Primeiras aulas do curso React Native: criando testes para sua aplicação

React Native: criando testes para sua aplicação

Fundamentos de Teste - Apresentação

Olá, eu sou a Natália Kelim Thiel, instrutora aqui da Alura e nesse curso vamos aprender a criar testes para a nossa aplicação React Native.

Esse curso é para você: Se você já está habituado a criar componentes de React Native no seu dia a dia; se você já utiliza hooks também, de efeitos e de estado, os hooks mais básicos mesmo; e se você quiser ir além disso, se você pretender criar aplicações confiáveis e com menos bugs. Porque, com testes automatizados conseguimos, criar uma automatização que rode no terminal e que faça testes para nós sem que precisemos testar toda a nossa aplicação manualmente.

O terminal é que vai testar para nós. Parece muito bom. Vamos ver que aplicação que vamos ter nesse curso, vamos ter uma aplicação que vai simular leilões. Vamos ter uma lista de leilões, uma tela com leilão, os lances e vamos também poder efetuar lances. Essa aplicação já vai centrar ali pronta para nós, só vamos testar. Porque isso aqui não importa muito qual aplicação é exatamente.

E o que vamos aprender nesse curso, já que já vamos ter a aplicação pronta? Vamos aprender a testar funções isoladas, também vamos aprender a testar componentes React Native mesmo, testá-los em memória e vamos testar hooks, vamos conseguir testar os nossos próprios hooks customizáveis além de simular funções. Se quisermos simular alguma função externa que requisita a API, sendo não queremos que requisite a API, podemos simular essa função sem que façamos de fato a requisição, mas o nosso teste continue funcionando.

É isso que vamos aprender nesse curso. Gostou do que viu aqui? Vamos lá.

Fundamentos de Teste - Fundamentos de Teste

Nesse vídeo vamos entender alguns fundamentos importantes de teste para que possamos saber quais são as possibilidades de teste da nossa aplicação e quais são os prós e contras de testar a nossa aplicação.

Para esse vídeo vamos considerar que a Roberta, que é uma desenvolvedora de software, é muito feliz porque trabalha em casa, ela trabalha Home Office. Ela estava lá indo na cozinha buscar um café, esperando o café passar e começou a checar o chat da empresa no celular e eis que ela se depara com um monte de mensagens falando que o que ela acabou de publicar está dando problema para os clientes. Ela fica desesperada e vai resolver o problema, mas ela fica pensando, depois que tudo isso passou, "será que ela podia fazer alguma coisa para tentar evitar isso ter acontecido?"

O que podemos tentar pensar em ajudar a Roberta, seria fazer esses testes automatizados. Como é que fazemos testes automatizados? O que são testes automatizados? Normalmente quando estamos desenvolvendo uma aplicação nós criamos uma funcionalidade nova e testa essa funcionalidade na mão mesmo preencheram os dados ou apertamos no botão para ver se o que fizemos está funcionando.

Mas, conforme a aplicação cresce fica difícil controlar onde que estamos mexendo exatamente. Porque pode ser que alteramos, como a Roberta alterou, uma coisa e fez com que causasse um bug em outra coisa que ela não chegou nem a perceber que tinha afetado. Por isso podemos fazer testes automatizados, podemos fazer automações, criar scripts que facilitam e nos ajudam a testar toda a aplicação antes de publicarmos e vermos se tudo que tínhamos funcionando antes também está funcionando agora.

Alguns desses testes automatizados podemos, inclusive, fazer no próprio terminal. Não precisamos abrir o simulador em todas as vezes e testar manualmente, podemos fazer com que o terminal faça isso para nós, o computador testa sozinho. Além do que já falamos, que poderia descobrir o problema antes, temos que fazer o teste. Temos aqui um gráfico de esforço e tempo sobre se vale a pena mesmo fazer testes automatizados.

Imagine que aqui no começo do gráfico, que fica à esquerda, seja o começo do nosso desenvolvimento da aplicação e a linha vermelha é como que estamos desenvolvendo a nossa aplicação de acordo com o tempo e o esforço.

Gráfico de linha. O eixo X corresponde ao Tempo e o eixo Y corresponde ao Esforço. Existem três linhas, todas saindo da posição 0 em X, mas acima de 0 em Y: a vermelha, que corresponde ao desenvolvimento "Sem testes", a laranja pontilhada, que corresponde ao desenvolvimento "Com testes ruins" e a verde claro tracejada, que corresponde a "Com testes". A vermelha é a que se inicia com menor Esforço, subindo levemente conforme avança no Tempo. Aproximadamente na metade do Tempo, ela sobe totalmente até o topo do Esforço. A linha laranja começa um pouco acima da vermelha no Esforço e segue no mesmo nível até um pouco depois da metade do eixo X, quando começa a ter um aumento constante de Esforço até o final do Tempo. A linha verde claro começa logo acima da laranja em relação ao Esforço, mas sobe linearmente à medida que avança o eixo Tempo.

Aqui no começo a linha vermelha, que é sem testes, uma aplicação sem nenhum teste vai ter menos esforço para começar a desenvolver porque não precisamos nos preocupar com os testes. Porém conforme vai passando o tempo, a aplicação vai crescendo e vai virando uma bola de neve. Temos essa linha aqui do esforço subindo porque as coisas vão saindo do nosso controle.

Temos também outras linhas aqui, por exemplo, essa pontilhada verde é a linha de Com testes. Se começamos criando testes, aqui começa já com um pouco mais de esforço, porque temos que pensar nos testes da nossa aplicação enquanto estamos desenvolvendo, mas podemos ver que o desenvolvimento continua com o esforço linear, ele continua aumentando esforço, mas não é um exponencial, que vira uma bola de neve que aumenta sem parar, ele vai aumentando conforme o tamanho da aplicação e o tempo aumenta também.

E temos a possibilidade de fazer testes ruins. O que é teste ruim? Isso é muito é subjetivo, não existe um teste ruim, mas o que podemos levar em consideração sobre testes ruins é você testar simplesmente por testar e não pensar no requisito ensino, o que aquela funcionalidade precisa fazer. Sempre quando testamos é legal pensarmos no requisito, no que queremos que o usuário consiga fazer e que continue funcionando não só em quanto ifs tem lá dentro, nesses casos.

Quando temos testes ruins começamos com um pouco mais de esforço, tem uma melhora, mas repare que também subimos um pouco mais rápido do que se tivéssemos testes de qualidade, teste de qualidade é sempre melhor.

Dado o que já vimos nesse gráfico, vamos entender um pouco mais sobre os tipos de teste. Eu falei que alguns podem ser rodados no terminal e outros nem tanto. Vamos ver o que são esses tipos de testes e o que podemos testar na nossa aplicação.

Começando com o teste de unidade que é o mais simples que temos e o mais comum também. Ele testa um comportamento isolado, por exemplo, temos no slide um teste de unidade que testa uma função soma e aí já temos escrito aqui no teste que "3 mais 2 deve retornar 5", queremos testar se a função, passando os valores 3 e 2, retorna o valor 5. Mais ou menos esse código aqui vai ser o que vamos fazer lá no JavaScript para testar essa função soma. Esse é um teste de unidade, ele testa uma única parte do código, um único método geralmente.

Depois do teste de unidade nós também temos o teste de integração, que testa parecido com o teste de unidade, onde vamos chamar uma função geralmente, mas ele testa uma integração com outros módulos da aplicação, com outras coisas externas à aplicação. Não é somente uma função de soma que fizemos dentro da nossa aplicação. Geralmente vai ser o banco de dados, uma conexão com a API, alguma coisa externa.

Por exemplo, esse teste do slide busca os cursos da API da Alura e ele espera que existam mais de 1300 cursos. Aqui vamos chamar uma função obterCursos() que vai bater na API, vai fazer uma requisição na API pela Web e vai retornar um resultado, digamos assim. Já está tudo pronto ali, a lista já está sendo retornada pronta para nós nessa variável resultado.

E aí pegamos qual que é a quantidade dos cursos, quantos cursos temos e verificamos se ele é maior que 1300. Nesse teste estamos fazendo um teste de integração, porque, fazendo requisição diretamente para a API, estamos fazendo requisição usando coisas que são fora da nossa aplicação.

Também temos um teste de interface, não só esses temos outros, mas o teste de interface testa uma aplicação real, algo mais parecido com que o usuário final vai utilizar. Podemos ver aqui que teremos que abrir a aplicação e rodar, ali por trás, um terminal também, mas vai rodar o simulador.

Porque demora mais, como vocês podem ver. Vai carregando, mas ele vai preenchendo para nós os campos e testando se as coisas estão acontecendo, como é o exemplo dessa tela de login, que foi feita para testar os testes, digamos assim, para demonstrar esse teste.

Ele faz vários fluxos e verifica o que passou, mas repare que ele demora muito mais. E é por essa diferença dos tempos que existe a pirâmide de testes. Nós podemos classificar os testes dentro de uma pirâmide, começando pelos testes de unidade que já vimos. Eles geralmente são a base da nossa pirâmide de testes, eles são os testes que vamos ter em mais quantidade. Porque temos uma menor fidelização, porém é mais barato e rápido. É barato fazermos esse teste da soma, não precisamos carregar nenhum simulador e nem nada tipo fazemos diretamente no terminal.

A fidelização é a semelhança com a aplicação real. Nos testes de unidade temos a menor semelhança com o simulador mesmo. Estamos mais distantes do simulador porque estamos testando funções do nosso código. Já no teste de integração temos uma fidelização maior, porque estamos testando a tela mesmo da aplicação.

Seguindo aqui na nossa pirâmide temos aqui no meio desses exemplos que trouxemos o teste de integração. Esse teste não vai ter em tanta quantidade quanto os teste de unidade, e está no meio da pirâmide, porque ele também precisa de mais recursos que os testes de unidade. Ele precisa que tenha conexão com a Internet, ele precisa acessar o banco de dados.

Às vezes pode até acontecer dele falhar, mas não quer dizer que a nossa aplicação está com problema, e sim que a API possa estar com problema. Por isso temos que tomar cuidado e ver a necessidade de fazer teste de integração. Às vezes podem fazer apenas teste de unidade.

Por fim, no topo da nossa pirâmide, que é onde teremos a menor quantidade de testes, há os testes de interface, de use interface, a sigla UI do inglês. Temos esses testes em menor quantidade porque é mais caro e mais lento, precisamos ter uma máquina que vai rodar esse simulador. Caso queiramos fazer esses testes na nuvem precisamos de um computador na nuvem que tenha a interface gráfica. Se fôssemos fazer só testes de unidade, não precisaríamos dessa interface gráfica, por isso que esse tipo de teste é mais caro e também mais lento.

Fundo branco com o título "Pirâmide de Testes" no centro superior escrito em azul escuro. Abaixo dele há uma pirâmide fragmentada em três partes. A base é azul ciano e está escrito "Unidade" no centro, a parte do meio é laranja está escrito "Integração" no meio e o topo é amarelo e está escrito "UI" no meio. Ao lado esquerdo da pirâmide há, na parte superior, o texto "Maior fidelização: Caro e Lento", seguida de uma seta que aponta para cima e para baixo. Na parte abaixo da seta há o texto "Menor Fidelização: Barato e Rápido". No lado superior direito da pirâmide, há o texto "Fidelização: Semelhança com a aplicação real".

Dado a pirâmide de testes, vamos ver um pouco mais de tipos e técnicas, porque não são somente esses tipos específicos de testes. Esses são os mais comuns e os que mais vemos por aí, mas temos outros tipos e técnicas principalmente dado o contexto. Como estamos no contexto de React Native temos algumas coisas diferentes, por exemplo, o teste de fluxo testa um passo a passo dentro da nossa aplicação, não é exclusivo do mundo mobile podemos testar um passo a passo dentro de praticamente qualquer tipo de aplicação.

Ele vai testar alguns passos da nossa aplicação, não necessariamente integrando com alguma coisa externa, mas fazendo com que as coisas dentro da nossa aplicação estejam funcionando. E ele vai ser bem usado também no React Native com o teste de componente, que é o teste de renderizar um componente em memória. O que podemos fazer é pegar o componente que escrevemos em JavaScript e transformá-lo como se fosse um JSON, em um objeto JavaScript, e executar algumas funções por cima dele.

É uma ótima alternativa para os testes de interface, porque os testes de interface precisam de uma configuração do simulador rodando para conseguir testar, e com o teste de componente não precisamos porque ele é renderizado em memória. E com essa renderização em memória podemos fazer um teste de fluxo apertando em botões, preenchendo coisas toda em memória, sem um simulador de fato, sem ser a interface de fato, e sim esses componentes simulados em memória.

E outra coisa que temos também em testes, que na verdade é uma técnica, é o TDD, o Test Driven Development ou Desenvolvimento Guiado por Testes. É uma prática que está aumentando cada vez mais, que é você fazer o teste primeiro e depois você cria a funcionalidade, você cria um teste pensando em todos os requisitos que essa funcionalidade precisa ter.

No começo, esse teste vai falhar, porque o seu método não está implementado ainda, e você vai implementando a funcionalidade e, quando todos os testes passarem, é porque a sua funcionalidade está desenvolvida. Você faz primeiro o teste e depois a funcionalidade.

Nós já falamos um pouco sobre os prós e contras de testar, mas vamos deixá-los mais explícitos aqui. Vamos começar pelos prós, primeiro é diminuir a criação de novos bugs. Podemos começar testando as coisas que estamos fazendo para diminuir o caso da Roberta, por exemplo, de ter alterado alguma coisa e ter refletido em outra parte do código que ela não tinha nem ideia. Diminui a criação desses novos bugs, incentivar códigos coesos, que são códigos que tem menos responsabilidade, códigos que fazem apenas coisas pequenas, então conseguimos fazer mais testes de unidade nesses códigos, e deixar o nosso projeto mais organizado.

É sempre bom termos códigos mais coesos para melhor entender as coisas e também para poder testar melhor cada parte do projeto. Se tivermos tudo em uma função só, como vamos poder testar mais detalhadamente? Fica mais complicado. E também, se você já é desenvolvedor, você pode perceber que um arquivo gigante com uma função única, também é muito difícil de dar manutenção, por isso códigos coesos é sempre uma boa ideia.

Ajuda na validação dos requisitos, como eu falei, bons testes sempre são pensando nos requisitos da nossa aplicação. Podemos fazer testes para validar a lista de requisitos, mesmo os funcionais, que podemos ter obtido do nosso cliente e tudo mais, podemos validar esses requisitos via testes.

E diminui o custo em longo prazo. No final, a longo prazo da aplicação, teremos menos custo de manutenção porque as funcionalidades vão ser bem mais fáceis de implementar e verificar se não está afetando alguma coisa que já estava funcionando antes. Por isso que diminui o custo, porém apenas em longo prazo.

E os contras são: aumenta a curto prazo, porque vamos precisar desenvolver os testes já quando vamos desenvolvendo a aplicação. No começo pode ser que fique mais lento fazermos, vamos precisar de mais esforço no começo, porém no final vai compensar. As métricas podem ser mal-entendidas. Como já falamos, testar uma função exige uma coisa que se chama cobertura de testes, e não quer dizer que se temos 100% do código coberto. Se aquele script viu que estamos testando todos os ifs, todos os fors, todas as sentenças da nossa aplicação, não quer dizer que testamos todos os requisitos da nossa aplicação.

Por isso precisamos pensar muito bem que esses números, às vezes tem algumas ferramentas que trazem esses números para nós, eles podem ser mal interpretados. Precisamos muito pensar nos requisitos e pensar menos na cobertura do teste em si. Esses são os contras, precisamos tomar cuidado com as métricas.

Como fazemos para aplicar testes em React Native? É o que vamos ver a seguir.

Fundamentos de Teste - Testes para sua aplicação

Para conseguirmos fazer testes automatizados precisamos ter uma aplicação na qual testar, ou isso, ou aplicamos o TDD, fazemos os testes primeiro e depois criamos a aplicação. Porém criar uma aplicação está fora do contexto do nosso curso de testes, já vamos ter uma aplicação pronta para aprendermos somente os conceitos de teste mesmo.

Você baixou essa aplicação seguindo as instruções de download e de preparação do ambiente nas atividades anteriores. Se você ainda não baixou, confere lá, tem o link do GitHub para você baixar e as instruções de como fazer isso.

Quando você baixa a sua aplicação, eu abri ela aqui no VS Code, vai ter as pastas aqui, mas a primeira coisa que precisamos fazer é instalar as dependências. Eu vou abrir o terminal. Aqui na barra superior tem um menu, "Terminal > New Terminal" e aí eu vou rodar dentro dessa pasta o npm install para instalar as dependências do meu projeto.

Vai ser criada essa pasta "node_modules" e as dependências vão ser baixadas da Internet. Pode demorar um pouco mais, dependendo da quantidade de dependências que você já tenha salvado no NPM, na sua máquina ou não. Também depende da Internet e da velocidade da sua máquina.

Depois de instalar as dependências, podemos tentar rodar o nosso projeto, vou dar um npm start. Esse projeto React Native é um projeto Expo, para facilitar aqui. Agora rodamos ele e eu vou mandá-lo rodar aqui no iOS. Eu já rodei no terminal, vou apertar "i" e ele roda no iOS. Ou você pode também escanear o QR Code para rodar no seu celular como já vimos em outros cursos aqui sobre Expo.

Está rodando a aplicação, porém está uma lista de leilões vazia, não tem nada na nossa aplicação. Isso está acontecendo porque ela aplicação depende de uma API de leilões, mas essa API não é externa, não precisa conectar com a Internet. Estamos utilizando o JSON Server, que é uma biblioteca que cria uma API com base em JSON. Para podermos rodar essa API, o JSON está aqui no "db.json", na raiz do nosso projeto.

Para podermos rodar essa API, criamos um script aqui no "package.json". Podemos ver que na seção scripts tem o script "api", que cria um "json-server" em um host, em um IP, e fica olhando, watch quer dizer que continua observando. Vai ficar mostrando os logs para nós e vamos escolher o arquivo "db.json" como o nosso arquivo de banco de dados mesmo. Podemos fazer requisições que ele vai alterar esse "db.json".

Só que temos um problema, porque para podermos rodar e acessar essa API a partir do simulador do Android, precisamos utilizar um IP. Está aqui o IP, esse é o IP da minha máquina na minha rede interna, esse não é o IP da Internet em si é o IP da minha máquina na rede interna. Precisamos descobrir qual que é o seu IP e qual que é o meu IP de novo também, porque IP muda dependendo do tipo de configuração do seu roteador. Cada vez que você vai iniciar a sua aplicação você precisa verificar se está tudo certo com seu IP.

No meu caso, eu já consigo ver que não está tudo certo com meu IP. Se expandirmos o terminal, quando o Expo roda, ele já diz onde que está rodando. Ele está mostrando aqui no terminal o meu IP local. Abaixo do QR Code temos aqui que ele está rodando lá no exp:// e o IP. Esse IP é diferente do IP que está aqui. Antes eu estava no 192.168.1.3, agora eu estou no 192.168.1.6. Eu preciso copiar esse IP e colar aqui no script dentro do "package.json".

Eu vou substituir e você faça isso também, procure qual que é o IP local da sua máquina. Se você estiver executando o Expo, ele vai aparecer aqui. Além do "package.json" precisamos alterar esse IP no nosso código-fonte, quando chamamos a API. Aqui é quando criamos a API, quando subimos a API e quando chamamos é em "src > servicos > apiLeiloes.js".

Aqui na "apiLeiloes.js" temos a nossa URL base, eu vou substituir o IP que está aqui pelo IP novo, que é o 192.168.1.6 na minha máquina, pode ser que seja diferente na sua máquina. E a porta aqui é a 3000 nesse caso, quando eu vou rodar ali ele vai rodar automaticamente na 3000, mas se você já estiver alguma coisa rodando pode ser que ele rode na 3001. Você tem que verificar quando você starta a API para ver se ele está na porta 3000 mesmo, mas essa é a padrão.

Vou salvar aqui e aí vamos rodar para ver como que ele vai rodar isso. Vou apertar no mais para criar um novo terminal e aí temos o script, como eu mostrei para vocês. Para rodar o script de API, eu vou rodar o comando npm run api, "Enter". E aqui já podemos ver que está na home 3000, 192.168.1.6:3000, confere se está rodando certo na sua máquina. Tem que aparecer essa mensagem aqui Watching, aguardando, para ver se está pegando mesmo.

E agora eu vou atualizar a minha lista de leilões na aplicação e pronto, agora sim temos uma lista de leilões carregando. Ele mostra que o log também fez uma requisição GET e o status foi 200, status sucesso para a rota “/leiloes”. A nossa aplicação vai ser uma lista de leilões e temos também uns detalhes aqui dos leilões e também podemos dar um lance. Se eu der um lance aqui maior do que os lances que já têm, ele vai aparecer aqui em cima.

Agora vamos dar uma olhada como é que foi feito isso por baixo dos panos. Ajustamos o IP e aqui no nosso "src", no nosso código-fonte temos uma pasta chamada "telas" e temos duas telas, que é a "ListaLeiloes", essa lista aqui de leilões da tela inicial e no "index.js" temos a "FlatList" que carrega os dados que vieram desse useListaLeiloes que é um hook que criamos, que já tem pronto aqui.

Na pasta "hooks > useListaLeiloes", esse hook obtém os leilões utilizando o repositório que é uma coisa um pouco diferente que temos agora. Está uma pasta chamada "repositorio" e dentro dessa pasta temos "leilao" e "lance" que são requisições para as rotas de leilão e requisições para as rotas de lance. A nossa aplicação segue esse fluxo. Temos o serviço que conecta com a API, o repositório faz a requisição para a API e os hooks transformam essa informação para pegarmos a nossa tela.

Essa pasta "negócio" vai nos ajudar também em alguns formatadores para formatar moeda, para formatar o lance, e também "validadores" para validar se o lance existe mesmo. Tudo isso pode ser testado na nossa aplicação. Nós também temos alguns componentes que é o cartão, esse componente de cartão aqui, e também tem o ícone, que é esse ícone com uma cor de fundo aqui.

Inclusive esse ícone podemos escolher dentro do "db.json". Aqui temos uma lista de leilões e cada leilão vai ter um ID, um nome, uma descrição, o valor inicial, um ícone, que vai estar de acordo com a biblioteca de ícones que já vamos ver, e a cor do ícone, que é uma cor hexadecimal.

Aqui embaixo também temos a rota de lances que vai ser basicamente uma tabela do banco de dados, digamos assim. Uma rota que vai armazenar o valor do lance vinculado a qual leilão que esse lance está sendo dado. E isso aqui tudo vamos gerar utilizando o Json Server para fazer as requisições.

Dentro da lista de leilões temos o componente de leilão, que é esse quadrado aqui. Nós também temos outra tela, que é a tela de leilão em si. Essa tela quando entra aqui, quando clicamos em algum leilão, estamos utilizando uma flat list para listar os lances do leilão. Também temos esse componente EnviaLance que está dentro dos componentes, que é formulário na parte inferior do aplicativo em que você pode digitar e apertar no botão para enviar o lance.

Nós também temos o lance em si, que é o cartão do lance, e o topo, que é essa parte do topo aqui, mostrando a imagem, o ícone do leilão e também algumas informações como o melhor lance, valor inicial, o nome do leilão e a descrição.

A respeito desse ícone que eu falei para vocês, vamos abrir o componente de ícone e ele vem lá do expo/vector-icons, FontAwesome5. Ele está dentro dessa biblioteca de fontes. Se você entrar lá na documentação vai encontrar e você pode trocar por qualquer outro ícone dentro dessa biblioteca do Expo de fonte.

E se você também ficou curioso sobre a navegação, podemos acessar navegação entrando aqui em "rotas > AppRotas" e vamos ter basicamente uma stack navigator, já estamos deixando todo o layout do react navigation, que é um biblioteca de navegação.

Todos já prontos aqui para que possamos fazer essa navegação de voltar, não precisamos implementar nada disso porque ele já cria para nós. Só temos duas telas, temos uma stack com duas telas, que é a tela de ListaLeiloes e a tela de Leilao que acabamos de ver.

E dado esse contexto, essa aplicação que já temos pronta vamos descobrir quais são as bibliotecas que vamos utilizar para aplicar os testes automatizados na nossa aplicação.

Sobre o curso React Native: criando testes para sua aplicação

O curso React Native: criando testes para sua aplicação possui 157 minutos de vídeos, em um total de 37 atividades. Gostou? Conheça nossos outros cursos de React Native em Mobile, ou leia nossos artigos de Mobile.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda React Native acessando integralmente esse e outros cursos, comece hoje!

Plus

De
R$ 1.800
12X
R$109
à vista R$1.308
  • Acesso a TODOS os cursos da Alura

    Mais de 1500 cursos completamente atualizados, com novos lançamentos todas as semanas, emProgramação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

Matricule-se

Pro

De
R$ 2.400
12X
R$149
à vista R$1.788
  • Acesso a TODOS os cursos da Alura

    Mais de 1500 cursos completamente atualizados, com novos lançamentos todas as semanas, emProgramação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Luri powered by ChatGPT

    Luri é nossa inteligência artificial que tira dúvidas, dá exemplos práticos e ajuda a mergulhar ainda mais durante as aulas. Você pode conversar com Luri até 100 mensagens por semana.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

Matricule-se
Conheça os Planos para Empresas

Acesso completo
durante 1 ano

Estude 24h/dia
onde e quando quiser

Novos cursos
todas as semanas