- TDD Test Driven Development. Write examples before implementation.
- BDD Behaviour-Driven Development is about implementing an application by describing its behavior from the perspective of its stakeholders. (The Rspec Book)
- RSpec (mention alternatives, write a simple hand sewn test)
require 'lib/svm' | |
data = [ | |
[5, {:year => 1987, :campy => 1}], | |
[3, {:year => 1978, :man_eating_monsters => 1, :horror => 1}], | |
[2, {:year => 1988, :teens => 1}] | |
] | |
predictor = SvmPrediction.from_svm_problem( data ) | |
puts predictor.predict(:year => 1988) |
In a large application, running all the tests at once using rake spec
can make it difficult to check the output of the test you're working on. Especially if you have many failing or pending tests. Run a single test by running rspec:
rspec spec/models/account.rb
You can be even more specific and run a specific example from a test file. For example, given the following tests:
11: describe "#deposit!" do
Definition: the practice of frequently integrating one's new or changed code with the existing code repository -Wikipedia
Merging new code into master often sounds awesome, but we've been learning the value of testing and the importance of a passing test suite.
But, as your projects grow, your test suite should grow as well. We're all lazy and forget to run the entire test suite everytime we create a new commit. For large projects, running the entire test suite can take hours. So we do what all lazy people do, make a computer to the work for us.
If you're working on an open source project, committing API keys or secrets to your repo is a big no-no. You wouldn't want anyone else making request with your keys, right?
So instead of putting those keys in app/config/initializers set then as environment variables in your shell. Here's an example for a Facebook API key:
export FB_API_KEY=3629346238763284623874623
As a new developer some potential employers are going to review your Github profile as part of the interview process. This doc covers some tips that should help you make a good impression. What this doc won't do is polish a turd.
Think of your experiences reviewing a Gem or other JS library on Github. Where do you look first? The README of course. What makes for a frustrating repo? One that doesn't:
- include a README.
- include install instructions (if applicable)