Tá Safo Em Ação na Estácio | IESAM

Nesse post vou contar para vocês sobre como foi o Ta Safo em Ação realizado na Faculdade Estácio Iesam no dia 09 de Março.

A primeira palestra foi de Lourdilene Souza sobre “Construção de Arquitetura para Software de Alta Performance”. Foi apresentado algumas dicas de como construir uma Arquitetura de Software que atenda as necessidades do cliente e por que todo desenvolvedor deveria se envolver na construção da Arquitetura.

eu

Lourdilene Souza

Continuar lendo

Anúncios

Diga, não pergunte

Diga, não pergunte – mais popularmente conhecido como tell, don’t ask – é um princípio da orientação a objetos que nos lembra de que, ao invés de pedir dados a um objeto, devemos dizer a ele o que fazer.

Dados e operações devem pertencer ao objeto, logo, você não precisa consultá-lo para depois agir em seu nome. Ou seja, você deve dizer ao objeto o que você quer que ele faça, e não perguntar sobre seu estado para depois tomar uma decisão. Por exemplo:

def street_name(user)
  if user.address
    user.address.street_name
  else
    'No street name on file'
  end
end

O método street_name está perguntando o estado de user para tomar uma decisão e retornar algo. De acordo com o tell, don’t ask, a implementação dessa lógica deveria ser responsabilidade de user e não do chamador, pois o tipo de implementação visto acima, viola o encapsulamento de user.

Uma solução bem melhor seria:

 def street_name(user)
   user.address.street_name
 end

 class User
   def address
     @address || NullAddress.new
   end
 end

 class NullAddress
   def street_name
     'No street name on file'
   end
 end

Agora, stree_name apenas diz o que quer e o objeto user se encarrega da lógica. Também fazemos uso do pattern NullObject, para deixarmos a solução orientada a objetos de fato.

Deste modo, passamos a pensar declarativamente ao invés de proceduralmente.

Referências
http://martinfowler.com/bliki/TellDontAsk.html
https://pragprog.com/articles/tell-dont-ask

Diário de um projeto: Palestras Coletivas

Você algumas vezes já sentiu estar fazendo algumas coisas no automático, sem saber exatamente porque você as faz?

O Tá safo inicia aqui uma nova série de artigos sobre os projetos da comunidade para apresentar como e porque eles surgiram, as discussões que motivam suas evoluções e os detalhes técnicos que podem balizar como os mesmo estão evoluindo.  Neste primeiro artigo, apresentamos o Palestras Coletivas.

O Palestras Coletivas é a plataforma online para marcação e divulgação de eventos relacionados à tecnologia em geral do Tá safo!

Homepage do Palestras Coletivas

Palestras Coletivas

Motivação histórica

Para entender um pouco melhor o contexto da criação do Palestras Coletivas é necessário compreender brevemente um pouco da própria história do Tá safo!

Continuar lendo

Mocks e Stubs com Rspec

mock-vs-stubs-clerb-presentation-1-728

Mocks e stubs são conceitos, muitas vezes de difícil compreensão, principalmente para desenvolvedores iniciantes em testes automatizados. Eu mesmo levei um tempinho para compreendê-los e nem sei se entendi muito bem. Por trás disso existe uma nomenclatura um tanto confusa e que não ajuda muito na compreensão dos conceitos. Vamos analisar como o Rspec trabalha com eles utilizando a biblioteca rspec-mocks.

Muitas vezes quando estamos escrevendo nossos testes, precisamos utilizar de objetos falsos. Em determinados cenários, o objeto real pode não estar disponível ou é necessário utilizar algum recurso externo que pode deixar o teste lento. Algumas vezes não precisamos testar o estado do objeto mas sim seu comportamento. Chamamos esses objetos falsos de Test Doubles ou Dublês de teste. Mocks e stubs são dois dos tipos especializados de doubles e são os mais utilizados.

Stubs

Simulam implementações dos objetos reais através de métodos que retornam valores pré-determinados. São métodos pré-configurados com as informações necessárias para a execução dos testes. Abaixo temos um exemplo de declaração de um test double.

  double = double('user', name: 'Tyrion Lanister')

O primeiro parâmetro é uma descrição do dublê que é usada na documentação e nas mensagens de falha. O segundo é o método stub setado com um valor qualquer. Vamos a um exemplo melhor. Queremos testar o método calculate_total_price da classe Order.


class Order
  attr_reader :total

  def calculate_total_price itens
    @total = 0
    itens.each { |item| @total += item.price }
  end

end

Podemos testar esse método sem instanciar o objeto real Item, através de stubs.


describe Order, "#calculate_total_price" do

  let(:itens) { [double(price: 10.0), double(price: 45.5)] }

  it "calculates the total price" do
    order = Order.new
    order.calculate_total_price(itens)

    expect(order.total).to eq(55.5)
  end

end

Na linha 3 setamos um array de doubles ao invés de uma array de objetos da classe Item. O teste irá passar. Isso é muito útil em testes  de unidade,, pois não precisamos acessar o banco de dados para pegar os dados do objeto Item que poderia ser um modelo do Active Record.

Mocks

São doubles pré-programados que irão criar expectativas que deverão ser satisfeitas pelos testes. Podemos usá-los quando queremos testar a chamada de uma api externa, por exemplo. Vamos dar uma olhada no exemplo abaixo.


class Westeros

  def geolocate(place)
    Geocoder.coordinates(place)
  end

end

O método geolocate da classe Westeros tem uma chamada da bilblioteca geocoder que retorna as coordenadas geográficas de um dado endereço. Precisamos testar se o método coordinates de Geocoder irá mesmo retornar as coordenadas? Acho que não. Os desenvolvedores da gem já fizeram isso. Precisamos mesmo é garantir que o método geolocate de Westeros irá chamar coordinates de Geocoder com o parâmetro correto. Para isso vamos usar um mock.


describe Westeros, "#geolocate" do

  it "retuns coordinates" do
    place = 'Ponta Tempestade, Westeros'
    westeros = Westeros.new

    expect(Geocoder).to receive(:coordinates).with(place)
    westeros.geolocate(place)
  end

end

Na linha 7 definimos as expectativas. Geocoder deve executar o método coordinates com place como argumento. O teste passa. Dessa forma testamos a interface de geocoder e não seu funcionamento interno. Um detalhe a parte é a dsl do rspec que deixa a leitura muito simples e agradável proporcionando um modo bastante elegante de se escrever testes.

conclusão

O rspec possui muitas outras inúmeras funcionalidades no que diz respeito a test doubles e testes regulares. A prática e a experiência irão melhorar ainda mais o entendimento dos conceitos de mocks e stubs, assim como os conceitos de testes automatizados. Existem uma infinidade de artigos sobre o assunto na internet. Vale a pena dar uma pesquisada no assunto.

Referências

https://github.com/rspec/rspec-mocks

http://www.infoq.com/br/articles/mocks-Arent-Stubs

Tá safo em ação com coding dojo na Faci

Aconteceu nesta quinta-feira o #tasafoemacao com coding dojo na Faci.

Inicialmente, Luiz Sanches apresentou como funciona a dinâmica de coding dojo para uma plateia de cerca de 50 alunos.

Luiz Sanches apresentando a dinâmica de coding dojoLuiz Sanches apresentando a dinâmica de coding dojo Integrantes do #tasafoemacaoIntegrantes do #tasafoemacao Integrantes do #tasafoemacaoIntegrantes do #tasafoemacao Ramon Rabelo apoiando a apresentação em meio ao auditório lotadoRamon Rabelo apoiando a apresentação em meio ao auditório lotado

Na sequência, os demais “senseis” apresentaram-se brevemente: Ramon Rabello, Paulo Moura, Geraldo Sequeira, Marcelo Andrade e Márcio Ferreira, se apresentaram e todos para suas salas, com as práticas de Android, Javascript, Ruby e Java.

A seguir, os relatos de cada um dos dojos: Java, Android, Ruby, Javascript.

Continuar lendo

Rails Girls Belém

Ícones pixelizados de um coração e um erlenmeyer, com a inscrição 'Rails Girls'

Mais ou menos em Julho, começamos a entrar em contato com a organização internacional do evento e com isso conhecemos a Natalie Volk, que nos deu apoio e, com sua contribuição, fizemos chamadas para mais meninas participarem da organização.

A Natalie, a comunidade Tá Safo! e o time (organizadoras e coaches) foram fundamentais para que tomássemos mais iniciativa e rumo, porque sentíamos a responsabilidade de fazer um evento tão bom quanto os demais que acontecem em outros países e aqui no Brasil. Isso aumentava nosso comprometimento em fazer um evento que realmente trouxesse mais conhecimento e motivação para as meninas.

Com as reuniões, sempre vinham mais ideias e dessa maneira foi possível galgar verdadeiramente o acontecimento do evento. Tivemos treinamento com os coaches, o apoio e patrocínio de empresas que apostaram nesse evento e isso aumentou nossas expectativas ainda mais.

Depois que as inscrições começaram, vimos que o número de pessoas interessadas era muito grande em comparação ao que havíamos definido. Ficamos muito felizes com o interesse das meninas, até chegamos a cogitar um espaço maior, mas por ser o primeiro evento, optamos por não arriscar tanto. E desde o início, a comunidade Tá safo! foi a que mais apoiou, patrocinou e deu credibilidade a esse evento.

Time de organização e coaches

As inscrições estavam bombando e ainda tinha mais de uma semana para o evento acontecer, começamos a cogitar lugares maiores. Queríamos todas as meninas presentes. Decidimos fazer um grupo menor que realmente estivesse interessado. Acreditem, quase todas estavam interessadas! Recebemos inúmeros e-mails de meninas reclamando o motivo de não terem sido selecionadas. Ah, sem esquecer dos rapazes, muitos meninos queriam participar também! A organização do evento então deu os ponta-pés iniciais. Tudo estava arranjado e finalmente…

Continuar lendo