marcelgsantos

Coisas que eu não sabia que eu não sabia sobre testes por Hugo Baraúna

• Por que fazer testes?
  • saber se o software está funcionando de maneira automatizada
    • não elimina os testes exploratórios feito de forma manual
  • manter custos de desenvolvimento em níveis saudáveis
  • ajuda na qualidade interna do código (design e arquitetura do código)
• Como avaliar a qualidade dos testes (se estão bem feitos)?
  • corretude - se o teste não está gerando um falso positivo
• adequação do tipo de teste - se o teste é o mais adequado para a situação

rondy

Queueing Theory references

General content

http://www.shmula.com/queueing-theory/
http://ferd.ca/queues-don-t-fix-overload.html
https://news.ycombinator.com/item?id=8632043
https://thetechsolo.wordpress.com/2015/01/25/queueing-theory-explained/
http://people.revoledu.com/kardi/tutorial/Queuing/index.html
http://setosa.io/blog/2014/09/02/gridlock/index.html

mgwidmann

# Elixir has lazily evaluated enumerable objects that allow you
# to work with enumerable objects like lists either only as needed
# or infinitely.

# Start up iex to play around
$ iex

# Typical enumeration is done eagerly where the result is computed ASAP
iex> Enum.map(1..10, fn i -> i * 2 end)
[2, 4, 6, 8, 10, 12, 14, 16, 18, 20]

rondy

OOP Design workshop

Part 1

• Initial step: Plan the user story (goals, acceptance tests).
• Getting familiar with the CEP SOAP API.
• Test as a documentation for external API usage.
  • Introduce spec/use_cases.
• byebug as a tool for API learning & discovering.
• Don't be bothered about duplication while enough use cases are not fully covered yet.

rondy

ORGANIC FRUIT'S WAY

• Escreva um test case que reflita a interação sob a perspectiva do usuário (entrada => processo => saída);
• Comece a implementação pela camada mais próxima do usuário ('controller', 'worker', 'views'). Caso a camada ainda não exista, comece pelo próprio spec file;

require 'rails_helper'

feature 'Awesome feature' do
 scenario 'User can do something awesome that will bring some valuable for him' do

rondy

Rondy Sousa (@plataforma.rondy): @brunno.santos, puxando o gancho no papo das descrições de MR, uma coisa que a gente costuma fazer é manter a descrição do MR no commit principal (title+descripton do MR batendo com o do commit).

A vantagem é que a motivação/propósito do MR ("pois o bundle da product já tem esse link salvo no banco") fica documentada no histórico do controle de versão (e agnóstico da plataforma de code review).

Brunno dos Santos (@brunno.santos): @plataforma.rondy interessante esse esquema que vcs usam de colocar a descrição no commit, mas o problema é definir qual é o commit principal, as vezes nem temos um. Como vocês lidam com isso?

Rondy Sousa (@plataforma.rondy): @brunno.santos, A gente faz squash dos commits antes de fazer merge no master, com o commit resultante recebendo o título + descrição do MR.

Na grande maioria das vezes, commits separados representam (ou deveriam representar) apenas "snapshots" de work-in-progress do MR. No momento do merge, eles acabam não acre

rondy

Requests specs x controller specs

Despite of they feel to be almost the same, there is a subtle difference between them: In request specs, you can exercise the full stack of a HTTP request (from routing to the view layer, so to speak).

Request specs also allows you to access more than one endpoint at a time, so you are able to test a whole scenario’s flow, whereas in controller specs you can exercise only one endpoint per test case (i.e., a single controller’s action).

# request spec
specify do
 get '/my-first/enpoint'