Vinicius Horewicz

My TODO list

2011-12-17T00:00:00-08:00

I use pending specs instead of TODO lists... nice tip from @wicz... it gives me an interesting view of what is missing.

I told Victor to write pending specs in place of using TODO comments within his code. I'm glad he liked the idea. I've been using the pending specs technique for a while and I'd like to share my thoughts why you should do the same.

First, you shouldn't add comments unless they are extremely necessary. As good developers, we strive to write clean, concise and self-explanatory code. We always refactor our code to make it as clear as possible for others to understand and to avoid to use of unnecessary comments. Using TODO comments go against our principles.

TODO comments are easily forgotten and overlooked. And your tests are not! How often do you ack TODO? And how often you run your test suite? I bet you've answered sometimes and everytime. And how about your CI server? I'm not sure if it knows anything about TODO comments, but it can certainly cope with pending tests.

TODO comments are just wrong! Specially if you're using them to convey something your code should be doing. What your code needs to do is its specification, and we all know the right place to put it.

So, are you still using TODO comments? I'd love to hear your opinions on the comments below.

First mutuo sketches

2011-05-12T20:25:08-07:00

Here is the digital version of the very first sketch I've made of mutuo architecture.

I know it's a raw draft, but doing this made me understand things clearly, so I guess it could ease things for you too. I'm not trying to follow any convention here, it's just a free-format sketch. Here we have the four core parts of mutuo: agent, tracker, receiver and the app.

The agent

The agent is the service which will be running in the peers. He's responsible for doing the heavy duty of the platform, which is monitor the others peers. It will somehow get a list of peers from the tracker, do whatever it has to do and report the results to the receiver.

I'm not being vague here on purpose, it's because there are lots of questions to be answered. For instance, I haven't defined yet how the agent will communicate with the tracker. Almost certainly it will run over HTTP, but I haven't defined if it will be long polling a REST API or use some kind of publish-subscribe mechanism, like pubsubhubbub or Faye. Probably I'll stick with the pubsub approach.

What I know, is that it's going to be implemented using node.js with CoffeeScript. Since I don't want to overwhelm the peers, I believe node.js will give the performance and small footprint I'm looking for.

The tracker

The tracker is supposed to be very similar to a BitTorrent tracker. It will keep track of the alive peers and serve them as a list.

It will also need to know if a agent who's trying to subscribe is a valid one. I'm thinking in a token-based authentication. Users will register agents in the app, which in turn will generate the tokens for them. That's why the tracker will need access to the app database.

The status database is where the tracker will store the peers' status. It could be a simple container data structure, or I could use something more interesting like memcached or redis or Kyoto Tycoon. It will be much easier to implement multiple trackers in the future using some of these. Now, which one? Probably I'll create an abstraction layer and delegate to the appropriate drivers. Thus I could play with all of them.

I want both tracker and receiver to be written in Ruby, and since both will be struggling with the C10k problem, I think it'll be a great opportunity to get my hands on Goliath, EventMachine or cool.io.

The receiver

As it's name suggests, it basically receives all the data retrieved by the agents. It will also need to authenticate the agents, so it needs access to the app database (though it's not on the graph, I've just realized it... my bad!)

I'm still thinking on how I'll store the massive amount of data. Could be redis, or for some type of data I could use RRD or Graphite. That would be nice when generating the reports.

Maybe I just answered my own question: It depends! It will depend on the type of the data. Is it time-based? Is it a sort of report, like page load? My brain's hurting now, so let's decide it later.

The app

The app will be the user interface for all the platform. I'll probably use Rails for this. Haven't thought much about it, but I do know it will have a simple, clean and very user-friendly interface. And maybe some realtime statistics using Websockets? Pusher looks interesting.

That's pretty much it, for a start at least. Was it worth reading all this? What do you think? Am I missing something? Please be my guest to post your opinions on the comments.

mutuo: peer-to-peer monitoring

2011-05-12T00:00:00-07:00

Meet mutuo, my brand new pet project! mutuo is a resources monitoring system based on a peer-to-peer architecture.

The first idea is to create something like pingdom, but in a fully distributed architecture similar to a BitTorrent network. We'll have peers (or agents) which subscribes to a tracker and get a list of other subscribed peers to ping. Ultimately the results are sent to another server and the reports accessible via an web app.

That done, we can extend mutuo to support other monitoring services with different protocols like WatchMouse, or full page load evaluations like Monitis and Page Speed, and even stress tests like Load Impact. I know it may look like I want to conquer the world, but that's not the point. I just want to raise the bar here and put on the table all my options. Like I said, it's a pet project, for fun and no profit =)

One thing I kept asking myself was "What I want with that?". And finally I was able to write my real intentions and motivations:

Learn. I want to learn new techniques, methodologies and technologies. I want to try Node.js, CoffeeScript, Redis and other things, and understand their better use. I want to learn more about event-based programming, concurrency, statistics and how to build and maintain an acceptable heterogeneous platform.
Practice. I want to practice, and I mean, A LOT! I want to try harder and harder. I consider myself an average programmer. I'm not dumb, but I'm not a genius either. I study a lot, but reading with no practicing will lead me to nowhere.
Push. I want to push myself to a new challenge. I want to face new problems and push myself to come up with ideas and solutions. I want to leave this comfort zone I am in.
Exposure. I want to expose my skills, my code and way of thinking. I want people to see what I am capable of and what I need to improve. And I really hope to get some feedback. Maybe I'll also have the chance to pair with some smart people like Clemens Kofler and Pat Maddox.
Give back. And last, but not least. I want to give back to the community. Be it Ruby, Rails or any other community. I want to give back my support. I want people to learn something from me, I want to help others like I was helped. In order to do that, I'll open-source everything produced, I'll do my best to keep the service running on my own servers and I won't charge a penny!

I guess that's it. I'll start pushing some code to the repo soon and continue to write my thoughts here, so stay tuned.

If you want to help me, feel free to email, fork, send you pull requests, discuss on the comments, whatever it takes to us to communicate. Any feedback will be really appreciated.

Wish me luck!

Hello Alfred App, how can I completely disable Spotlight?

2011-05-04T00:00:00-07:00

UPDATE 2011-05-10: STOP RIGHT NOW! After a few days I wrote this, I realized that Alfred uses the metadata services, which means if you disable it, Alfred will stop working. Why I couldn't find anything about that in their docs? I'm still using it, though I'm not sure if I'll keep it.

So, finally I'm giving Alfred App a try. It reminds me a lot the (discontinued?) Enso from Humanized.

Since I'll be using Alfred in favor of Spotlight, I want to disable the latter. Googling a bit gives us a lot of ways to do it, but all looks a bit intrusive and destructive to me. I don't want to delete Spotlight, I just want to disable it!

Spotlight consists of a set backend and frontend tools. Metadata server (mds), Metadata worker (mdworker), etc. do the hard work of indexing the volumes and monitoring file changes. The frontend is basically the small loupe that appears in the menu bar (that's enough, we don't need all the details.)

The first thing is to disable all backend. You can stop the mds from indexing your volumes:

$ sudo mdutil -a -v -i off

OK, but it won't stop Spotlight from initiating after a system restart. According to other solutions, you could delete files from /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/Support, but since I don't want to destroy anything, I chose to reset the permissions:

$ sudo chmod 000 /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/Support/*

Great! ps aux | grep md shows no metadata processes running. dmesg shows no error. But looking at Console.app (/var/log/system.log) I see that launchd is trying to start mds every 10 seconds!

May 3 11:41:11 wicz com.apple.launchd[1] (com.apple.metadata.mds[879]): posix_spawn("/System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/Support/mds", ...): Permission denied
May 3 11:41:11 wicz com.apple.launchd[1] (com.apple.metadata.mds[879]): Exited with exit code: 1
May 3 11:41:11 wicz com.apple.launchd[1] (com.apple.metadata.mds): Throttling respawn: Will start in 10 seconds

Well, I don't wanna lose those CPU cycles. So chmod isn't a acceptable solution and neither is deleting those files. Probably the error would be No such file or directory.

The acceptable solution is to disable mds in launchd. So, RTFM! manpage launchctl* has the answer we're looking for:

$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

Now to the frontend. I didn't find a way to disable this nicely. It seems to be somehow hard coded in the SystemUIServer.app. So here we have to use the chmod approach. At least it is just a one time failure.

5/3/11 11:31:46 AM SystemUIServer[256] Error loading /System/Library/CoreServices/Search.bundle/Contents/MacOS/Search: dlopen(/System/Library/CoreServices/Search.bundle/Contents/MacOS/Search, 265): no suitable image found. Did find: /System/Library/CoreServices/Search.bundle/Contents/MacOS/Search: open() failed with errno=13

OK, errno=13 is an EACCES Permission denied. No loupe appears on menu bar. But I wonder if it will crash future system updates. So I ended up just renaming the damn thing.

$ cd /System/Library/CoreServices/Search.bundle/Contents/MacOS
$ sudo mv Search _Search

It seems everything is fine till now. If something stop working I'll update this post. And if you know something I'm missing, please let me know in the comments.

*Just a few notes. Reading the launchctl manpage it says:

-w Overrides the Disabled key and sets it to true. In previous versions, this option would modify the configuration file. Now the state of the Disabled key is stored elsewhere on-disk.

WTF!? "elsewhere on-disk"? FWIW, the "elsewhere" is /private/var/db/launchd.db/com.apple.launchd.peruser.<userid>.

And launchctl looks at many different places for .plist files. So if you're getting errors from apps that you've already uninstalled but are still trying to start, you might want take a look into:

~/Library/LaunchAgents -- Per-user agents provided by the user.
/Library/LaunchAgents -- Per-user agents provided by the administrator.
/Library/LaunchDaemons -- System wide daemons provided by the administrator.
/System/Library/LaunchAgents -- Mac OS X Per-user 
/System/Library/LaunchDaemons -- Mac OS X System wide daemons.

HAI SPARROW, CAN I HAS FIXED WIDTH FONTZ? KTHXBYE

2011-05-04T00:00:00-07:00

UPDATE 2011-12-15: I'm no longer using the trial version, like said in the comments months ago. I'm using this with Sparrow Version 1.5 (1043) and it's working flawless. No code signatures problems either.

Gotta say, I just love the Sparrow Mail App! It's interface is simple and clean. It just does everything you need, and nothing you don't.

Only one thing I can complain: Why in hell I can't set a fixed width font for plain text messages? I don't like HTML emails and I never use that fancy editor. I like plain old fixed fonts! Just like my terminal.

If you're like me, dark days are over! All you need is tweak some CSS and voila! Inside /Applications/Sparrow.app/Contents/Resources/

// message-editing.css
body { font-family: Monospace; }

// conversation.css
div.-sparrow-messageBody { font-family: Monospace; }
div.-sparrow-quickReplyTextContents { font-family: Monospace; }

Testing subdomains and redirects with Cucumber

2009-12-09T00:00:00-08:00

UPDATE 2011-04-13: If you're on Mac OS X, forget all the /etc/hosts and PAC thing and go for Pow.

The other day I was writing some Cucumber features for a Rails app that relies on subdomains for creating per-user contexts. It seems that Webrat can't handle subdomains and redirects the way I expected.

A Little Background

I hate when I have to access 127.0.0.1 or localhost:3000. Typing all these numbers, dots and colon doesn't feel comfortable at all. I like domain names, and since I am developing a subdomain-aware app, I want to be able to access using names. That said, I configured my Firefox with a PAC file that routes *.local to my server running at 127.0.0.1:3000 (oh man, if you're still using /etc/hosts you're so 2000-and-late! =p).

Here's how it looks like. You can grab more details here.

function FindProxyForURL(url, host) {
  if (shExpMatch(host, "*.local")) {
    return "PROXY 127.0.0.1:3000";
  }
  return "DIRECT";
}

Now I am able to access johndoe.app.local, foobar.app.local, etc. No numbers, no colon, just NAMES! =)

My ApplicationController implements a simple before_filter that checks for a valid account, otherwise redirects to a fallback page. Something like this:

before_filter :account_required

def current_account
  @current_account ||= Account.find_by_subdomain(request.subdomains.first)
end

def account_required
  unless current_account
    flash[:error] = :account_not_found
    redirect_to fallback_url
  end
end

You can have more on subdomains as accounts here, here and here.

The Scenario

The feature was a simple sign in.

Given the foobar account
When I go to foobar's sign in page 
And I fill in "user_session[email]" with "foobar@test.com"
And I fill in "user_session[password]" with "1234"
And I press "Sign in"
Then I should be on dashboard
And I should see "Welcome, foobar"

The Caveats

By default, Webrat uses www.example.com as host for testing. Since it was trying to sign in to a account that doesn't exist (the Given creates foobar), it was being redirect to the fallback url, so it couldn't find the form fields. Knowing that Webrat's RailsAdapter uses ActionController::Integration::Session, we can easily solve this by overwriting the host name to use in the next request. Our Given should look like this:

Given /^the foobar account$/ do
  Foobar.create(...)
  host! "foobar.app.local"
end

Now being able to fill in the form, after submitting it, I still wasn't sent to the expected page. I was willing to see the dashboard, but it was rendering /session, which means I wasn't authenticating at all, even passing valid credentials... WTF!? Then dumping the ActionController::Response object, I verified that it was actually redirecting (@status => "302 Found"), so I decided to investigate Webrat.

Webrat's behavior is to follow any redirects, except for external ones. And subdomains aren't considered as externals. Digging a little deeper, people have reported similar problems and patches (although I've tried none) here, here, here and here. Since the problem seems that Webrat shows some really deep love to example.com, I came up with a ugly-and-fast-but-it-works solution:

Set a domain in my environment.rb:

APP_DOMAIN = "app." + case RAILS_ENV
when "production" then "com"
when "cucumber" then "example.com"
else "local"
end

And changed the above Given step to host! "foobar.#{APP_DOMAIN}".

Bar green, code clean, life moves on.

User-friendly location-aware web apps

2009-12-07T00:00:00-08:00

Who have never ever filled a form like this please stand up.

Anyone? Anyone?

Well, you'll have to agree with me that filling forms like this is a PITA! But I understand that may be necessary in certain cases. Maybe in apps that people really need this granularity, this is an easy way to get each field of an address separately.

But if it's not your case and like me you can sacrifice the formalism in order to user experience, I present you geo-autocomplete. It's a nice jQuery plugin to autocomplete location using Google Maps v3 API and Google Static Maps v2 API.

Now you are able to change that gigantic form to a simple textarea, and still have a nicely formatted address. And since the plugin queries the Google Maps v3 API Geocoder, you also get latitude and longitude values. It's fast and smooth, definitely worthwhile to give it a try.

Escrevendo boas User Stories

2007-11-19T00:00:00-08:00

Como bem sabemos, um dos princípios dos processos Ágeis é satisfazer o cliente, agregando valor ao produto final. De certa forma, para que essa tarefa possa ser realizada com sucesso, é preciso saber exatamente as necessidades desse cliente.

Felizmente com algumas estórias e feedbacks já é possível ter uma boa idéia de onde devemos chegar. Mas é importante ressaltar que a “qualidade” das estórias influencia diretamente em todo o processo.

As estórias apresentam três aspectos críticos, os quais devem ser obrigatoriamente lembrados no momento de sua criação. São eles: Cards, Conversation, Confirmation. Ou 3C.

Cards — Estórias são escritas em cartões ou post-its. Na verdade o que importa aqui é o tamanho! A sugestão dos cartões e post-its é pelo fato de serem pequenos. E cartões pequenos naturalmente forçam estórias pequenas, de duas a três linhas no máximo.

Conversation — A estória escrita no cartão serve como um lembrete, uma maneira de identificar uma funcionalidade que foi conversada e discutida entre os clientes e desenvolvedores.

Confirmation — Depois das funcionalidades terem sido discutidas e escritas nos cartões, o cliente define (implícita ou explicitamente) uma maneira de validar esse pedido. Geralmente essa confirmação é feita com testes de aceitação.

Para criar boas estórias, ainda devemos focar em seis atributos: INVEST

Independent — Estórias devem ser independentes uma das outras. Dependências entre estórias geram problemas de planejamento e priorização, sem falar que dificultam bastante nas estimativas.

Negotiable — Estórias não são contratos. Como dito anteriomente, estórias são lembretes para funcionalidades discutidas (negociadas) entre o cliente e os desenvolvedores.

Valuable — Na mesma linha dos processos Ágeis, como dito no início deste post. Estórias devem agregar valor para o cliente.

Estimatable — Os desenvolvedores devem ser capazes de estimar o tamanhos das estórias. Geralmente estórias incompletas ou muito grandes (complexas) são difíceis de serem estimadas. Portanto invista em discussões e quebre em estórias menores quando necessário.

Small — “Tamanho é documento”. Essa regra é valida para a criação de boas estórias. Como dito anteriormente, estórias grandes dificultam as estimativas. Bem como estórias muito pequenas. Quebre ou agrupe dependendo do caso.

Testable — Estórias devem ser possíveis de serem testadas. Um teste que é executado com sucesso, prova que a estória foi desenvolvida com sucesso, atingindo as necessidades do cliente. Estórias que não podem ser testadas geralmente especificam requisitos não-funcionais do software, e não uma funcionalidade diretamente.

Além do 3C e INVEST, vejamos mais alguns pontos. Foque as estórias no “O que” e não no “Porque”. Estórias não devem apresentar termos técnicos e nem os mínimos detalhes das funcionalidades. Lembre-se, elas são apenas lembretes do que foi discutido anteriomente.

Quando possível aplique o “Quem”, “O que” e “Como”. Por exemplo: “O visitante pode se cadastrar no portal pelo formulário”, “O visitante confirma seu cadastro por email”, “O usuário é capaz de salvar seus favoritos”. Mas cuidado com o detalhismo!

Use e abuse de metáforas. Você vai perceber como fica fácil de explicar (ou entender) suas idéias quando você consegue comparar com algo concreto, do dia-a-dia das pessoas. Sem falar que assim você consegue definir um vocabulário comum com o cliente.

Incentive o cliente a escrever as estórias. Assim você acaba forçando-o a explicar com clareza as suas necessidades e muitas vezes ajuda também a esclarecer possíveis dúvidas.

Para finalizar, abaixo um trecho retirado de [1], que explica quase tudo em um único parágrafo:

The story is the unit of functionality in an XP project. We demonstate progress by delivering tested, integrated code that implements a story. A story should be understandable to customers and developers, testable, valuable to the customer, and small enough so that the programmers can build half a dozen in an iteration.

Referências/Leitura recomendada:

[1] Planning Extreme Programming. Kent Beck, Martin Fowler
[2] Essential XP: Card, Conversation, Confirmation. Ron Jeffries
[3] User Stories Applied: For Agile Software Development. Mike Cohn

Dicas valiosas para sprints

2007-10-23T00:00:00-07:00

Olá. Bem, é como dizem por ai: “Life got real!”. Mas, enfim, estou aqui de volta.

Ainda tratando de sprints. Seguindo na mesma linha do post anterior. Acho que ficou claro que não é sensato abraçar cegamente o que é sugerido pela literatura, e sim saber reconhecer a essência do que é proposto e conseguir adaptar e aplicar à sua realidade. E além do mais, saber aplicar tais conceitos a cada caso é o tipo de tarefa que só se consegue realizar com a prática do dia-a-dia. E foi justamente com a prática do dia-a-dia que eu percebi alguns detalhes nos meus projetos. Seguinte:

Fixe os dias da semana para marcar suas reuniões de planejamento e retrospectiva (sprint planning e review). Por exemplo, todos os plannings acontecem na segunda-feira e todos os reviews na sexta-feira. Dessa forma você acaba criando um vínculo e fica mais fácil de todos se organizarem e dificilmente alguém vai esquecer da reunião;
Certifique-se que os dias dos sprints planning e reviews estão “funcionando” pra você. O que eu quero dizer com funcionando, é se estão sendo reuniões produtivas. Nos meus primeiros projetos eu reservava a segunda-feira para o planejamento e a sexta-feira (da outra semana) para as retrospectivas. Tiro no pé! Ninguém, nem a equipe, nem o Product Owner estavam motivados para começar a semana com uma reunião. Estas sempre começavam atrasadas e era nítido que o pessoal ainda estava “regulando a marcha lenta”. Muito menos encarar uma retrospectiva de 4 horas em plena sexta-feira! Bastou trocar os dias e a coisa começou a funcionar;
Lançar novas versões do produto na sexta-feira pode não ser uma boa idéia. Ninguém quer voltar para casa, muito menos correr o risco de perder o final de semana com aquela preocupação de que algo pode dar errado. Uma coisa que funcionou comigo foi definir um deadline na quinta-feira. E deixar a sexta-feira apenas para algumas tarefas administrativas e reviews;
Crie tags no seu sistema de controle versão para cada sprint. Isso se você estiver utilizando controle de versão, pois se não estiver, você definitivamente deveria!
Evite entregar tudo o que foi produzido apenas ao final da iteração. A medida que as tarefas forem sendo finalizadas, disponibilize para o cliente. Agilidade está diretamente relacionada a feedback. Se você deixar para entregar tudo que foi feito ao final do sprint, você só tera o feedback do cliente no próximo sprint, o que pode acabar atrasando as coisas, haja vista já existem tarefas definidas para esse (próximo) sprint. Esse assunto também foi abordado neste excelente artigo do Alisson Vale, inclusive batizado com um nome bastente adequado: “Síndrome da Iteração Inacabada”.

Bem, por hora é isso. Como cada empresa ou projeto, cada situação tem suas peculiaridades, eu gostaria que vocês compartilhassem suas experiências com relação a esse assunto. Os comentário estão abertos. Caso você não tenha passado por isso ainda, espero que esses tópicos possam te poupar algum tempo.

Sem mais.

Tamanho ideal de sprint/iteração (Scrum/XP)

2007-10-10T00:00:00-07:00

Antes que comecem as críticas, quero deixar claro que o título escolhido foi proposital. Não por provocação, pelo contrário, mas para tentar abrir os olhos de quem ainda acredita que seguir à risca a bibliografia é sempre a melhor solução. E acaba ferindo (mesmo que cegamente) um dos princípios mais importantes da Agilidade: Adaptação.

Não me recordo o número, mas posso afirmar que não foram poucas as vezes que ouvi ou li alguém questionando sobre o tamanho dos sprints ou iterações. Se eram obrigados a trabalhar com 30 dias, ou se optando por um valor diferente estariam certos ou errados.

Para quem esperava uma solução simples e objetiva, sinto muito. A verdade é que não existe bala de prata, nem certo ou errado. Não existe um tamanho ideal que se aplique a todas as ocasiões. Cada caso é um caso. Mesmo em uma equipe que não sofre alterações de pessoal, um tamanho adequado para um projeto, pode não ter a mesma eficiência em outro.

O Scrum sugere sprints com 30 dias (um mês) de duração (“Do I need to stick to a month time frame?” em Scrum FAQ, ou na versão traduzida). O XP sugere ciclos semanais. Durante meu treinamento Certified ScrumMaster foi proposto sprints de 28 dias, pois facilita visualização em termos de semanas. Além desses, eu já tive oportunidade de trabalhar com sprints de 1 e 2 semanas. O que eu sugiro pra você: Experimente! Só assim você vai ser capaz de dizer o que é apropriado para cada ocasião. No mais, eu só posso citar alguns pontos que devem ser levados em consideração para a sua decisão:

Escolha uma duração a qual seja agradável trabalhar, tal que a equipe consiga manter um ritmo sustentável. Sprints muito longos podem levar à procrastinação (Síndrome do Estudante). Já sprints muito curtos conseguem ser bem estressantes quando algum imprevisto acontece;
Requisitos mudam com freqüência (i.e., o cliente muda os planos constantemente ou é incapaz de especificar com clareza o que deseja). Se for pra algo dar errado, que seja agora e não daqui 15 dias. Ou seja, quanto antes você perceber que esta no caminho errado, o esforço para voltar atrás é menor. E você só conhece esse caminho a partir do feedback, o que (geralmente) acontece mais frequentemente em sprints curtos;
Semelhante as incertezas do cliente, deve-se ponderar as incertezas da equipe. Pois esta pode ser incapaz de dizer o quanto consegue trabalhar por iteração ou desconhece de aspectos técnicos do projeto;
Da mesma forma que os requisitos podem mudar, o mesmo pode acontecer com suas prioridades. O seu tempo de resposta para eventuais mudanças esta intimamente ligado à duração dos sprints;
Preparação (overhead) para os sprints. Suponha que antes de cada sprint todo o sistema precise passar por uma bateria de testes, ou que todo desenvolvedor deva reinstalar seu sistema e ambiente de desenvolvimento por medidas de segurança da empresa. Sem dúvida sprints curtos não são a melhor escolha nesse caso. O ideal seria reduzir ou eliminar estes impedimentos, mas nem sempre isso é possível.

Bem, se você tinha dúvidas com relação o tamanho dos seus sprints, espero esses tópicos sirvam como ponto de partida para uma possível mudança. Mas não esqueça que até mesmo as mudanças visando melhorias têm seus efeitos colaterais. Portanto, uma vez definida uma duração apropriada para seus sprints, respeite esse valor, pois só assim você será capaz de manter um ritmo (velocidade) de trabalho.

Inspect and Adapt!

TDD em: O que testar?

2007-10-04T00:00:00-07:00

Quando comecei a implantar desenvolvimento guiado por testes (TDD) na empresa em que trabalhava, tive a sorte de fazer parte de uma equipe de desenvolvedores bastante competente. Com apenas uma apresentação de poucos minutos e duas semanas de prática, quase todos já conseguiram captar que a essência do TDD não é apenas validação de código, mas também a especificação de determinada funcionalidade.

Tive apenas um caso em especial. Depois de algumas sessões de programação em par passei o teclado para o companheiro. Ele virou pra mim e disse: “Tá, e agora?”. Nós já tínhamos discutidos anteriomente o contexto da funcionalidade, mas mesmo assim ele estava repleto de dúvidas sobre o que realmente implementar

Para tentar esclarecer um pouco as dúvidas, fiz uma breve pesquisa na bibliografia e cheguei nos conceitos Right-BICEP e CORRECT.

Right – Are the results right?

Dados valores de entrada e seus respectivos valores de saída, verifica-se se a implementação esta de acordo, ou seja, se os resultados estão certos.

B – Are all the boundary conditions CORRECT?

Verificar se os valores estão dentro do domínio, dos limites aceitáveis. Por exemplo, uma validação de preenchimento de um campo, ou ainda se este foi preenchido na formatação adequada. Veja abaixo a descrição do acrônimo CORRECT, que descreve algumas condições de limites.

I – Can you check inverse relationships?

Alguns métodos podem ser verificados aplicando a sua lógica inversa. Por exemplo, para verificar o resultado de uma divisão, podemos comparar o dividendo com a multiplicação do divisor com o quociente, adicionado ao resto.

C – Can you cross-check results usings other means?

Semelhante a relação inversa, podemos verificar os resultados por outros meios. Podemos certificar o sucesso de uma inserção de uma elemento em um vetor, verificando se o tamanho deste antes da inserção e acrescido de um, é igual o tamanho depois da inserção (1 + Ni = Ni+1).

E – Can you force error conditions to happen?

Verificar como a aplicação se comporta em situações adversas. Podemos forçar um erro simples, com uma passagem de parâmetros incorreta, por exemplo. Mas não podemos esquecer dos outros diversos possíveis problemas do dia-a-dia. Uma falha na comunicação, espaço em disco que se acaba, memória insuficiente, etc. Uma maneira de testar isso é a utilização de objetos Mock?. Mas isso já é pano para outra manga =)

P – Are performance characteristics within bounds?

Nesse caso não queremos testar o desempenho em si, mas sim se a curva de desempenho se mantém estável, mesmo variando os cenários. Suponha que os testes de uma busca em um vetor de tamanho N passam em tempo t. E se agora o vetor for de tamanho N+M, os testes continuam passando em tempo t+m?

Como muitos dos problemas aparecem na verificação das entradas e saídas, é importante ter bem definido o seu domínio, ou limites (boundary). Felizmente temos mais uma ferramenta para nos ajudar nessa definição.

Conformance – Does the value conform to an expected format?

Verifica se o valor em questão esta de acordo com o formato estabelecido. Por exemplo, um CPF ou CNPJ, ou ainda uma estrutura mais complexa como uma árvore binária.

Ordering – Is the set of values ordered or unordered as appropriate?

Diz respeito a ordenação dos valores. Suponha os processos de uma cafeteira (bom exemplo!): colocarFiltro(), colocarPo(), colocarAgua(), servirCafe(). Esses processos necessariamente precisam estar nessa ordem, caso contrário ninguém vai conseguir beber o valor de saída.

Range – Is the value within reasonable minimum and maximum values?

Dado valor deve estar dentro do domínio. Por exemplo, o preenchimento do ano de nascimento em um formulário [1900,2007].

Reference – Does the code reference anything external that isn’t under direct control of the code itself?

Verificar se um cenário referencia ou depende de outro fora do seu escopo. Suponha um portal de compras. Antes de adicionar qualquer produto ao carrinho, o usuário deve ter iniciado uma sessão (efetuado login). Existem pré e pós-condições que devem ser satisfeitas para passar o teste.

Existence – Does the value exist (e.g., is non-null, nonzero, present in a set, etc.)?

O teste mais intuitivo, acho. Verificar e um determinado valor de fato existe. Se certo parâmetro foi preenchido.

Cardinality – Are there exactly enough values?

Outro simples também. Se a cardinalidade, quantidade dos parâmetros passados é suficiente.

Time (absolute and relative) – Is everything happening in order? At the right time? In time?

Devemos verificar se execução de diversos processos em ordem. Cada um executando no momento certo. Lembra do exemplo da cafeteira? Também se aplica aqui. Eu disse que era um bom exemplo =). Você também pode imaginar uma linha de produção.

Acho que isso é um bom começo. Mas gostaria de deixar bem claro que isso não se trata de um guia, muito menos de uma receita de bolo. São apenas alguns lembretes para facilitar e aprimorar a implementação dos seus testes. Caso você tenha se interessado neste tópico e queira a versão in extenso, você DEVE ler Pragmatic Unit Testing in Java with JUnit.

Feliz TDD!