Tuesday, September 19, 2017

Stubs, Mocks, and Spies in Rspec

There's a number of different terms we use in testing to describe how we're setting up the tests. Are we stubbing? Mocking? Spying? All of the above? What do they even mean?

1. Stubs

These are just canned responses. You stub out methods so that when they're called, they just return something (anything you want). If they're not called, nothing happens. 

Rspec stubbing: https://relishapp.com/rspec/rspec-mocks/v/2-14/docs/method-stubs

Example

allow(obj).to receive(:message).and_return(:value)

You can do this either both real objects and doubles.

2. Spies

These are objects that you set up with canned responses (like stubs) that also record information about the calls made to that method (was it called? what was it called with? How many times?). 

Rspec

Example

allow(Invitation).to receive(:deliver) 

or

invitation = spy('invitation')

Followed by the assertion

expect(invitation).to have_received(:deliver)

3. Mocks

These are objects that have already been instrumented with expectations. They're like spies in that actions are recorded but they also go a step further to automatically verify the behavior when the test is exercised.

Example

logger = double("logger")
account = Account.new logger

expect(logger).to receive(:account_closed)

account.close

State verification vs Behavior verification 

Verification is the act of verifying that something occurred in some manner. In testing, we rely on either state verification or behavior verification to ensure that objects are behaving in the way we expect them to. 

In the testing world, state verification is verifying the test through the state of an object. What's the current value of variable X? In other words, what's the current status of this object? Does it match up with expectations? 

Behavior verification takes a different approach. Behavior verification is not concerned with what state the object is in - it's only concerned with the fact that certain actions occurred in some manner (regardless of how they changed the objects state). 

According to Martin Fowler, only mocks insist on behavior verification. In other words, unlike stubs and spies, only mocks are preprogrammed to perform behavior verification. With mocks, you don't really have a choice to do state verification. 






Sunday, September 10, 2017

Spinning up a rails app using Heroku in < 5 min

It's really amazing how you can have an app running in production in < 5 minutes using Heroku. Below are the minimal set of required steps to serving a basic static page to Heroku.

Pre-requisites
  • Heroku Account
  • Heroku CLI
  • Rails CLI
Create and and commit the app

rails new app-0 -d postgresql && cd app-0

rails generate controller welcome

touch app/views/welcome/index.html.erb && echo 'Hello World' > app/views/welcome/index.html.erb

Add root 'welcome#index' to the config/routes.rb file 

git add . && git commit -m 'first commit'

Deploy app to Heroku

heroku login

heroku create

git push heroku master

heroku ps:scale web=1

heroku open

Topics:

  • GIT
  • PostgreSQL
  • Rails
    • Routing
    • Code generation
  • Heroku
    • create
    • ps
    • open
    • Default Rails Server: WEBrick
      • Single threaded server vs multithreaded server