ruyadorno, danielfilho, thiagopnts, That's it. Teve alguma coisa ruim que viram nos dojos que já participaram? Eu posso usar as lições de vocês pra melhorar os dojos que facilito. E pra sugerir melhorias pro pessoal que ensina isso em treinamentos. x)
Podem desabafar que eu vou gostar de receber feedbacks sobre essa dinâmica =x
ruyadorno
saquei... massa
ayr-ton
Se puder dar uma olhada no artigo da knowledge21. Lá eles falam mais sobre as técnicas que o pessoal usa pra ser mais produtivo.
thiagopnts
ayr-ton é mais coisa pessoal mesmo, não curto TDD nem pair programming
paulohp
lol
ayr-ton
thiagopnts, Oxi. Teve alguma experiência ruim com algum time que usava TDD?
Ou projeto?
thiagopnts
ayr-ton não, as vezes até faço, mas não é algo que curto fazer
ayr-ton
thiagopnts, acha que perde tempo? Dá trabalho? Como costuma fazer? x)
thiagopnts
ayr-ton prefiro fazer os testes depois, não tenho mto saco pra red-green-refactor :P
ayr-ton
aaaaah
tendeu
Tipo, o teste unitário, segundo o pessoal do cucumber tem um nome que faz as pessoas não entenderem bem o objetivo deles. Com o nome teste as vezes a gente acha que faz mais sentido escrever testes depois, já que aí teria o que testar.
Mas a grande mágica do tdd, é especificar as expectativas sobre o código, antes de ter o código.
thiagopnts
tbm não faço 100% coverage
ayr-ton
Aí você já sabe a assinatura do método, o que ele vai retornar, sem ter o método.
E quando vai fazer o método, já sabe o que ele precisa retornar.
obetomuniz joined the channel
thiagopnts
acho desnecessario
ayr-ton
100% de coverage é meio tenso, concordo. Ahaha
Mas cobrir o que pode dar bug reopen é bem útil.
Também fica fácil de saber quando uma funcionalidade nova vai quebrar o código e quanto dele.
Mas as vezes é quase impossível cobrir 100%.
thiagopnts
no meu mundo ideal(com a linguagem ideal) eu confiaria no compilador e só escreveria testes para partes criticas do sistema
ayr-ton
A gente escreve o código de qualquer jeito da primeira vez, pro teste passar, daí refatora pra ficar mais amigável.
E o teste diz que quebrou a parada no nosso refactor.
thiagopnts, A treta é que o compilador não vai validar erros de lógica.
Pode estar tudo passando pelo compilador, sem nenhum erro de sintaxe e etc, mas estar retornando expectativas diferentes.
thiagopnts
dai uma parte critica que seria testada
ayr-ton
É válido :D
Fica a critério do time definir a porcentagem de cobertura.
E também existem testes diferentes pra testar certas coisas. Como testes de integração pro pessoal ver se o layout está quebrando e essas coisas.
Se o layout muda muito, não faria sentido fazer essas coisas, por exemplo.
Os testes seriam como a expecificação viva do código.
thiagopnts, normalmente você faz apps com js pra backend ou frontend?
thiagopnts
ayr-ton frontend
ayr-ton
thiagopnts, aí você faz apps que normalmente consomem um backend rest?
thiagopnts
ayr-ton sim
ayr-ton
Nesse cenário, eu vejo que não faz sentido, por exemplo, fazer testes unitários que validem se a camada de negócios funcionam, já que o backend já deveria ter testes pra isso. Seria um trabalho tenso.
Mas você pode validar se as chamadas existem, se os callbacks certos acontecem, quando usa observers e essas coisas.
Pra poder xingar o backend guy caso ele faça algo que quebre as suas chamadas.
Ou que algum observer não pare de funcionar sorrateiramente.
No Angular.JS, eles chamam isso de MidwayTests.
thiagopnts, anima participar de um dojo uma hora dessas? o/
prbc_
Se eu tenho uma aplicação usando angular routes, e tenho uma botão de logout, como faço pra quando ele clicar, deslogar e redirecionar pra pagina de login?
thiagopnts
ayr-ton talvez :)
ayr-ton
prbc_, No teu scope principal, quando for rodar, tem que injetar o seu módulo de autenticação. Aí só carrega a app caso esteja logado. Pode fazer isso pra uma rota específica também. http://stackoverflow.com/questions/20969835/ang...
So cuidado pra nao conseguirem fazer bypass disso.
Se o backend nao verificar a token, nao vai adiantar verificar so no front.
Se o backend tratar, fazer esse check no root scope resolve.
paulohp has quit
thiagopnts, na hora do dojo de hoje à noite venho aqui chamar. Na quarta que vem tem de novo. 18h GMT -4. A gente faz uma pausa pra pizza e volta =x
thiagopnts
ayr-ton se eu estiver por aqui eu vou
ayr-ton
\o/
leolrrj has quit
leolrrj joined the channel
matheuslc
bem interessante, fica gravado o dojo?
eliezerb has quit
ayr-ton
matheuslc, É uma ideia. A gente colhe as lições aprendidas no final do dojo pra pegar um feedback do sentimento da galera. O que foi bom e ruim. E sempre tem o código.
Se quiser participar \o/
matheuslc
ayr-ton: ah sim, eu vou ta na faculdade provavelmente, mas achei bem foda, aonde eu vejo o código depois?
ayr-ton
A gente publica no git.fpf.br, mas não tá acessível externo. Vou colocar no github.com/ayr-ton o/
matheuslc, hoje vai ser em coffescript
E ninguém manja de coffe =x
Fizemos em dogesharp outro dia e o pessoal não parava de rir.
matheuslc
ayr-ton: vixi, mas da nada na
leolrrj has quit
não*
ayr-ton
matheuslc, dá nada não?
leolrrj joined the channel
matheuslc
ayr-ton: é, da pra enteder o código..
ayr-ton
matheuslc, dá sim (:
matheuslc
ayr-ton: então, depois passa aqui, quero ver como que é
ayr-ton
O código costuma ficar bem bonito, por causa do jeito que é construído.