I’ve recently started acceptance testing my JavaScript, and it has been something of a rough ride. Using Capybara/RSpec with the poltergeist JS driver, I kept encountering seemingly random failures which nearly forced me to give up on acceptance testing my JS at all. In the end, I managed to work around the issues:

With the help of an excellent post by Avdi Grimm, I installed database_cleaner and configured it to work in the Capybara/poltergeist environment. However, this led to issues where tests didn’t seem to be properly cleaning up after themselves.

You’ve deployed a couple Rails apps to Heroku. You know all about heroku create and git push heroku master. What’s next?

So much

Rails is complex. Really, hideously complex. Imagine all the individual parts that make up a car. Now imagine all those parts are one small component of a larger machine. That’s how complex Rails is. So one would imagine that teaching Rails would entail teaching from the ground up. That is, introducing the principles of programming, followed by a study of each of the major parts of the stack, concluding with an examination of the way those parts interact. Traditionally, the process takes years. I’m enrolled in a program that’s supposed to compress those years of material into ten weeks.

Here at Launch Academy, test-driven development is a way of life. Every app we write, no matter how small, is expected to have excellent test coverage from the start. Further, we’re expected to practice outside in development. Our cycle goes like this:

• Compose user story (the narrative we expect to drive a feature)
• Draft acceptance criteria (what needs to happen for that narrative to work)
• Code a failing acceptance test (a script based on an acceptance criteria which emulate user input and watches for a desired output)
• Write a failing unit test (a program that tests a component required to meet the acceptance criteria)
• Implement (actual programming. Yay!)

Suppose we have a suspiciously simple Rails blogging app with the following models:

class User < ActiveRecord::Base
  has_many  :posts,
            inverse_of: :user

  attr_accessible :name, :email
end

class Post < ActiveRecord::Base
  belongs_to  :user,
              inverse_of: :posts

  attr_accessible :body, :title
end

This done, we could issue:

new_user = User.create
new_post = user.posts.create

Then, when we call new_post.user, we are returned new_user. Great! Well…actually this is OK, but the association could be more explicit about the relationship between Users and Posts.