Estou postando aqui um curso de 6 video aulas(em média 1 hora cada) que está disponível no Youtube. Notei que está com outro usuário, porém quem gravou e editou foi o pessoal do Marakana. Aqui tem muito material para utilizar Test Driven Development em Rails.

Vale a pena comentar que as video aulas são em inglês. Vale comentar que esse curso é de 2010(utiliza Ruby 2.3.8), algumas coisas estão desatualizadas, mas a teoria não está desatualiza. Mas esse é o preço do progresso tão ágil de nossa comunidade.

O curso foi dividido em semanas, cada semana é uma das aulas abaixo, posto aqui a programação do mesmo abaixo:

 

 

Week #1:

The economics of testing

Testing in layers, design patterns

Toolbox: RSpec with Rails

Rspec & Models

 

Week #2: 

A culture of testing: Why TDD? How to TDD?

Testing & Data Dependencies

Toolbox: Fixtures, Factories, Mocks & Stubs

 

Week #3: 

Controller Testing

View, Helper, Routes Testing

How much is enough? How much is too much?

 

Week #4:

Refactoring code & tests, custom matchers

API Testing

Remote data setup

Cucumber for API testing & documentation

 

Week #5:

Integration Testing - when and how?

Toolbox: Cucumber, Selenium & Friends

Page Object Pattern

 

Week #6:

TDD - what next?

BDD, Agile Process, XP -> VDD: Value Driven Development

Advanced/Special Requests

 

 

Week #1:

 

Week #2:

 

Week #3:

 

Week #4:

 

Week #5:

 

Week #6:

 

 

O pessoal do Marakana a algum tempo atrás postou um vídeo de uma palestra feita no EngineYard muito legal sobre Rubuto. Vale apena dar uma conferida nesse vídeo, principalmente se você tem interesse em desenvolver para Android com Ruby.

(Fonte da Imagem: Tumblr - http://hugoriehl.tumblr.com/) 

	Nota
	Este post tem a ver com ruby, rails e estudos, porém não é diretamente técnico.

Um dos nomes que eu respeito no cenário do Ruby on Rails nacional é Carlos Brando. 

Você deve estar perguntando: Cain, que diabos é isso? por quê você está mencionando o nome do Carlos aqui nesse post?

Não estou fazendo deste post um "altar de popularidade" para o mesmo, muito pelo contrário, pois o mesmo não precisa. Muitos conhecem o mesmo da comunidade Ruby e ele inclusive juntamente com Rafael Rosafu fazem o Grokpodcast.

Estou aqui apenas para divulgar mais alguns trabalhos do mesmo que algumas pessoas podem não conhecer. Sigo o blog Nome do Jogo e gosto muito da maneira que Carlos posta, discute e mostra conteúdo. Existem três palestras que foram ministradas pelo mesmo que relamente você deve assistir se estiver com a pilha baixa na hora de estudar algum tipo de assunto(principalmente ruby e rails).

Uma delas tive a oportunidade de assistir juntamente com muitas outras de muito boa qualidade no evento Ruby on Rails no Mundo Real(em 2009). Sinceramente demonstra que o GURU SP está na frente de diversos outros GURU's nacionais e acredito que o mesmo seja o mais velho.

Mas voltando ao assunto deste tópico, a primeira palestra que posto aqui é sobre o caminho que muitos profissionais da área de desenvolvimento enfrentam:

 

Você está fazendo sua Parte?

 

Essa palestra começa com um conto, que esboça muito bem a realidade de muitos da área(A Estagnação) e como podemos nos estagnar ainda mais não indo atrás de novidades e atualizações. Eu pude ver estagnação durante minha vida acadêmica e hoje em dia no trabalho vejo a mesma com meus olhos todos os dias ao conversar com alguns profissionais da área. Alguns parecem tentar fujir da mesma porém só fazem cada vez mais coisas pra apertar a coleira.

No final vejo que para alguns não importa muito o ato de desenvolver ou adquirir conhecimento e sim obtenção de dinheiro sempre(ou apenas ficar falando sobre maneiras de obter o mesmo).

 

Só os Imaturos não Testam.

http://blip.tv/agaelebe-eventos-de-tecnologia/ruby-rails-no-mundo-real-carlos...

 

Essa é a palestra que tive oportunidade de assistir pessoalmente. Sinceramente esboço muito o ciclo de vida de um desenvolvedor. Eu vivencio muito do que é dito nessa palestra e acredito que muitos de vocês que estão lendo esse artigo também. Novamente a abordagem da estagnação profissional, o maior vilão existente. 

A palestra tem enfoque em testes e qualidade de software no final de tudo, e eu concordo muito com isso desde que conheci metodologias de desenvolvimento ágeis[isso me lembra uma outra palestra que possívelmente ainda postarei sobre XP do Vinícius Teles da ImproveIT].

 

Como Ruby on Rails pode te tornar um programador Pior.

http://blip.tv/agaelebe-eventos-de-tecnologia/14-edted-carlos-brando-2078174

 

Nessa última palestra, o assunto abordado é mudança de paradigma e como ele pode ser bom e ao mesmo tempo ruim. Carlos Brando comenta sobre suas experiências passadas com uma outra linguagem de programação e novamente a estagnação é abordada.

 

Conclusão

 

Se você tem uma idéia ou um projeto, coloque a mão na massa. Aprenda um pouco de teoria e comece a desenvolver logo, afinal é só com a prática que as reais dúvidas irão aparecer, se você ficar parado o mundo não irá se acostumar com o seu passo, você que tem de se acostumar com o fluxo, adaptar e mudar.

Porém você possui uma das chaves mestras pra isso, você é um desenvolvedor e pode criar uma solução para milhares de pessoas utilizarem, esqueça a sociabilidade e foque em funcionalidade.

Deixo aqui meus agradecimentos a Hugo Borges(agaelebe) que gravou duas das três palestras, sem ele não teríamos esse conteúdo disponibilizado em alta qualidade para podermos assistir quando quiséssemos.

 

Ingredientes

remarkable - 4.0.0.alpha4

Rails - 3.1.1

Sqllite3 - 1.3.4

RSpec - 2.6.1

Annotate - 2.4.1.beta

Resultado

 

https://github.com/cain-alchemist/remarkable_test

 

 

Introdução

 

Remarkable atual está na versão Alpha 4.0.0.alpha4, mas é um framework muito bom e que auxilia bastante os tests em Rails principalmente para testes com validações e modelos.

Eu tive alguns problemas para configurar o mesmo e por isso estou compartilhando os problemas aqui.

Inicio

Vamos iniciar criando uma nova aplicação Rails.

 

 

	Nota
	O argumento -T é para suprimir a criação dos testes, já que iremos utilizar RSpec juntamente com Remarkable.

 

Agora devemos editar nosso GemFile.

 

	Nota
	A gem Annotate não é um necessária para rodar o RSpec com Remarkable, mas utilizarei a mesma abaixo para auxiliar na hora da criação dos testes para o modelo.

Após, devemos rodar o bundle para instalar todas as dependências.

 

 

Em seguida devemos iniciar o rspec em nosso projeto.

 

 

Fazer os requires corretos em seu spec/spec_helper.rb logo abaixo de "require 'rspec/rails'"

 

 

A parte das configurações está completa, agora vamos iniciar nossos testes para poder testar nosso modelo.

 

Meio: A criação do Modelo

 

O Modelo que criaremos é um Character(Personagem) genérico de um jogo de RPG de fantasia medieval.

 

 

Geramos o modelo juntamente com seus testes, mas os mesmos estão vazios. 

 

 

	Nota
	A gem Annotate não é um necessária para rodar o RSpec com Remarkable, mas utilizarei a mesma abaixo para auxiliar na hora da criação dos testes para o modelo.

 

Depois da criação do modelo, iremos criar os bancos de dados(dev,test e prod).

 

 

E realizar as migrações.

 

 

Porém podemos encontrar um problema muito grande na hora de rodar os testes, afinal as migrações foram feitas apenas para o ambiente de desenvolvimento(rake db:migrate utiliza o ambiente atual como base para a migração dos bancos).

Temos de utilizar o comando abaixo ou mudar o ambiente no rspec_helper.rb de test para development.

 

 

Agora vamos utilizar a gem annotate apenas como uma boa prática para lembrarmos de quais campos inserimos em Character sem que tenhamos de observar o arquivo schema.rb após a migração para o banco de dados.

 

 

Após gerar as anotações no modelo o próximo passo é testar o mesmo com o Remarkable.

Vamos alterar os testes do modelo em spec/models/character_spec.rb. Pode-se observar que a gem annotate nos providenciou os campos do modelo no spec do mesmo, o que facilita bastante para se lembrar quais campos devem ser devidamente testados.

 

 

Após fazer os devidos testes, os mesmos devem falhar, você pode rodar os testes com o seguinte comando na raíz do seu projeto:

 

 

Agora é a hora de fazer os mesmos passarem:

 

Conclusão:

Configuramos o Remarkable para funcionar com o Rails 3.1. É valido notar que outras versões mais antigas do Remarkable não estão funcionando muito bem com o Rails 3.1, por isso é necessário usar a versão alpha do mesmo. Seguindo esses passos você poderá configurar o Remarkable de forma fácil em sua aplicação fazendo mais eficientes para seu modelo.

 

 

Hello everyone. There is a thread here about the compatibility of the Annotate gem and Rails 3.1.x. Basically it's not working with the gem annotate 2.4.0 so in order to continuing using this gem we will have to wait until the next release or use the beta version.

You can include on your Gemfile:

gem "annotate", " ~> 2.4.1.beta1"

 

And everything should be fine.

You can check the original thread of the discussion here on github: https://github.com/ctran/annotate_models/issues/28

 

 

Eu não sou um Apple Fanboy. Gosto muito do sistema operacional MAC OS X e provavelmente utilizaria o mesmo se ele fosse de arquitetura aberta em outras máquinas que não são Apple, sei que muitos fanboys podem discutir que ele perderia performance e blá blá blá. Não estou aqui porém para falar se gosto ou não da Apple ou até mesmo do Steve Jobs. É um fato que perdemos um grande inovador no ramo da tecnologia, não importa se você é um fan, ou hatter da apple, acredito que você deve estar pensando o mesmo.

Por isso deixo aqui minha homenagem a Steve Jobs, por ter feito diversas inovações e ter deixado um otimo legado a esse mundo.

Eu me lembrarei sempre dele como ele estava em uma palestra ministrada em Stanford em 2005.

 

 

 

 

 



 

 

 

	Nota
	Identificador = Nome ou palavra utilizada para identificar um determinado elemento da linguagem(ex: variáveis locais, métodos, variáveis de instância, constantes, etc

Pretendo ser breve nesse artigo por se tratar de um assunto muito simples.

O estudante de Ruby pode ter se perguntado, como o ruby interpreta os seus identificadores e faz a diferença entre os mesmos. Alguns dos mesmos são muito diferentes um dos outros devido a alguma peculiaridade, dificilmente geram questionamentos.

Se você já utilizou um editor com sintaxe highlighting já teve oportunidade de notar que alguns elementos como uma variável local e um método não tem muita diferença em estética em si(obviamente quando executados em um escopo sem a utilização de objetos). Ambos parecem muito a mesma coisa para nós em certos lugares, então como seria que o ruby diferencia isso?

Abaixo deixo um exemplo relativamente confuso para iniciantes em ruby, mas parcialmente ignorado por mais experientes na linguagem.

O que você acha que o ruby irá retornará abaixo? o método ou a variável local:

 

Se você está pensando que a ordem dos elementos irá alterar o produto final, faça o teste, você irá ter o mesmo resultado mesmo que você declarar o método primeiro e a variável local depois.

 

Bem o algoritmo de interpretação seria mais ou menos assim:

 

 

1. Faz uma comparação com a lista de palavras chaves(keywords) da linguagem, se o identificador for igual a alguma das palavras da lista, o ruby interpreta a keyword como devido.
2. Possui se o Identificador possui um @,$ ou letra capitalizada(variável de instância, variável global e constante) logo no início do identificador.
3. Se não é 1 ou 2 o Ruby identificará se existe um sinal de igual(=) a direita do identificador. Se existir o Ruby irá assumir que é uma variável local sendo instanciada.
4. O restante é interpretado como uma chamada de método.

 

 

Conclusão

 

Essa é uma armadilha que dificilmente irá acontecer com você em ruby(por diversos motivos). A mesma pode as vezes acontecer quando você estiver testando algo no IRB, mas quando você estiver desenvolvendo em ruby por estarmos desenvolvendo elementos com o paradigma da orientação à objetos 99% das vezes dificilmente você deixará isso escapar aos seus olhos.

Mesmo assim é interessante entendermos como o ruby interpreta esses elementos(nesse caso os identificadores) para que possamos utilizar suas vantagens e desvantagens a nosso favor, entendendo assim a linguagem em maior profundidade.

 

 

 

Se você estiver utilizando o spork 0.8.5(Versão estável quando este post foi redijido) ou até mesmo uma versão do Spork com a rc <= 5 elas possuiem alguns problemas no momento.

Ele rodará a primeira vez normalmente em conjunto com o guard ou autotest e até algumas vezes sozinho, mas depois dará um estranho erro de deprecation falando que o mesmo será deprecated e que temos de fazer o update da versão.

O Erro é mais ou menos esse:

 

NOTE: Gem.latest_load_paths is deprecated with no replacement. It will be removed on or after 2011-10-01.

Gem.latest_load_paths called from /Users/mc/.rvm/gems/ruby-1.9.2-p180/gems/spork-0.9.0.rc5/lib/spork.rb:107.

 

Esse é um erro já admitido pelos desenvolvedores do spork então utilize a 0.9.0.rc8(não ouvi dizer muito mal dessa rc, mas já vi diversos erros reportados pela rc9).

Lembre-se de reiniciar sua máquina(virtual ou física) pois algum processo do spork pode estar rodando ainda. Você pode matar o mesmo também, ele estará rodando na porta 8989 provavelmente.

Acredito que seus testes automatizados em conjunto com o spork não terão problemas agora.

 

Essa é uma dica muito simples para inserir syntax highlighting para Gemfiles nos seus projetos Rails se você utiliza o Textmate.

Vá na aba Bundles do Textmate e selecione Bundles Editor:

Selecione a Aba Languages ao invés de Show All:

Escolha Ruby on Rails e Mude a linha abaixo:

fileTypes = ( 'rb', 'rxml', 'builder' );

para:

 

fileTypes = ( 'rb', 'rxml', 'builder', 'Gemfile' );

 

Feche e vá para Aba Bundles novamente, Bundle Editor => Reload Bundles.