Lições que o Chai pode te Ensinar

Transcript

1. Lições que o Chai pode te Ensinar Lucas Fernandes da Costa
2. O QUE É CHAI? Antes de qualquer coisa… * Quem usa
3. Chai é uma library de assertions para o Node • API fluida e flexível • Escrita muito próxima do inglês • Extensível • Sem dependências externas chaijs.com * Falar do chaining * Suporte à plugins/extensões * Dependências são todas nossas
4. Alguns números * Lembrar de falar da licença * Último domingo 180 clones * 4.0.0 vindo
5. GETTING INVOLVED
10. Algumas páginas depois…
16. O QUE EU APRENDI
17. SOBRE COMO COMEÇAR
18. Código não é tudo, mas é bem legal • Documentação é tão importante quanto código • Responda issues • Leia Pull Requests * Maior parte do tempo eu respondo e reviso em vez de codar * Responder dúvidas dos outros usuários e dar dicas
19. Você já sabe o suficiente, você só precisa entender o código • Entenda o software antes de tentar entender o código • Não tente entender tudo de uma só vez • Resolva um problema e, na dúvida, pergunte * Entenda o core * Deixe outras utilidades pra depois
20. Fique atento ao contexto • Leia as referências • Veja o histórico (gitk) • Use a caixa de busca * Uma issue pode travar a outra * Ver no histórico referências a issues ou PRs
21. SOBRE AJUDAR A TE AJUDAREM
22. Seja amigável e acessível • Nada é óbvio • Comece suas respostas agradecendo • Código não é pessoal • Use esse emoji :smile: Um bom tom motiva as pessoas a continuarem contribuindo * Vários canais de comunicação (Slack, IRC, Email) * O foco é conseguir mais contribuidores e levar o projeto pra frente
23. Seja o mais informativo possível • Não diga apenas o que deve ser feito, diga como fazer • Compartilhe links (Artigos, MDN…) • Faça referências (issues parecidas, PRs anteriores) • Escreva exemplos Os primeiros commits são sempre os mais difíceis * No começo os PRs se faziam quase sozinhos, orientações muito precisas * Exemplos de uso ajudam na hora de saber o escopo * Depois dos primeiros commits se entende o contexto
24. Organize suas issues • Crie labels de acordo com: • A dificuldade da tarefa • O tipo de tarefa • Deixe claro quando um PR é desejado/necessário
25. SOBRE FAZER CÓDIGO a.k.a. engenharia de software (e outras coisas mais) Agora começa a parte de ferramentas
26. Documentação • Código documentado ajuda tanto quem utiliza quanto quem escreve o software • Documentação gerada a partir de uma só fonte (código) diminui a possibilidade de informações conflitantes • Dox + Jekyll
27. Mantendo as Dependências Atualizadas Pull Requests automáticos sempre que uma dependência sai do range do package.json ou quebra o build
28. Semantic Versioning Seja gentil com seus dependentes MAJOR.MINOR.PATCH BREAKING.FEATURE.FIX npm install —save lodash ^x.x.x é perigoso
29. Code Review • Todos os commits são revisados por pelo menos duas outras pessoas • O objetivo do review é unicamente garantir a qualidade do código • Pratique o egoless coding
30. Extensibilidade
31. Extensibilidade • Mantém o core enxuto • Funcionalidades de nicho ficam encapsuladas em outros módulos menores • Eventualmente plugins transformam-se em features oficiais
32. Cobrindo código em todas as plataformas • Browserify • Karma • SauceLabs
33. Cobrindo código em todas as plataformas 1. Código passa pelo browserify 2. É instrumentado usando Istanbul 3. Testes locais rodam no PhantomJS e node 4. Testes remotos rodam em "todos" os browsers 5. Resultados de todos os ambientes são mergeados (lcov-result-merger) 6. Resultados são enviados para o coveralls
34. Testando IE fora do Windows
35. Modularização (no sentido mais literal da palavra)
36. Usando o Chai para testar o Chai
37. Usando o Chai para testar o Chai Já sabemos que um determinado resultado está correto, só queremos saber se a asserção sobre ele vai falhar ou não
38. TOUR GUIADO +
 DICAS
39. Vamos aumentar esse número
40. Obrigado! lucasfcosta lfernandescosta fernandesdacostalucas@gmail.com lucasfcosta.com