- 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)
- saber se o software está funcionando de maneira automatizada
- 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
The list below includes 3098 deleted tweets by rjs.
There are also 2 tweets that are indicated as not currently deleted by the Twitter API that have been scraped from pages of deleted tweets (as replies, etc.). These possibly undeleted tweets are included for context and are indicated by a (live) link.
You grok SOLID. You practice TDD. You've read Sandi's book…twice. You rewatch Destroy All Software monthly. You can pronounce GOOS. You know your stuff!
But some of your coworkers say your code is too complex or confusing for them. You might rush to conclude that must be a them problem.
But doubt lingers: what if they're right?
I've used Cucumber quite a bit on my last job. It's an excellent tool, and I believe readable tests are the way to the future. But I could never get around to write effective scenarios, or maintain the boatload of text that the suite becomes once you get to a point where you have decent coverage. On top of that, it didn't seem to take much for the suite to become really slow as tests were added.
A while ago I've seen a gist by Lachie Cox where he shows how to use RSpec and Capybara to do front-end tests. That sounded perfect for me. I love RSpec, I can write my own matchers when I need them with little code, and it reads damn nicely.
So for my Rails Rumble 2010 project, as usual, I rolled a Sinatra app and figured I should give the idea a shot. Below are my findings.
# This is part of my .pryrc. | |
# I put this at the section where I load Rails stuff, so I can use Pry instead of IRB | |
# for my Rails Console sessions | |
# Once this is loaded, just run the display_routes method from the console to see the same output that rake routes displays. | |
# I think it's better because I always leave a Rails console session running :) | |
require 'rails/application/route_inspector' |
class Credential | |
include ActiveModel::Validations | |
attr_accessor :screen_name, :oauth_token, :oauth_secret, :token, :description | |
validates_presence_of :screen_name, :oauth_token, :oauth_secret, :message => 'required' | |
validate :user_exists, :unless => :errors? | |
def initialize(attributes = {}) | |
attributes.each { |k, v| set_recognized_attribute(k, v) } |
By default, Rails 3.2 loads everything in app/javascripts and everything in app/stylesheets on | |
every page, despite controller-specific file naming. If you want to load controller-specific | |
files only on views from their respective controllers, you need to change the manifests and the | |
layout. The basic idea is to NOT require the entire trees, but only specific subfolders, in the | |
manifests, and then load the controller-specific files separately in the layout. | |
Any file you DO want loaded on every page should be placed in app/assets/javascripts/general or | |
app/assets/stylesheets/general. | |
For this to work in production, you also need to ensure that the individual files are precompiled by modifying your production.rb file, listing all of the controller-specific files. |
=Navigating= | |
visit('/projects') | |
visit(post_comments_path(post)) | |
=Clicking links and buttons= | |
click_link('id-of-link') | |
click_link('Link Text') | |
click_button('Save') | |
click('Link Text') # Click either a link or a button | |
click('Button Value') |