Speedy Tests

Testing
1
Learn how to keep your TDD cycle snappy and keep your test suites short. Ben and Joe demonstrate an ideal setup for TDD, with focused test runs integrated into the editor. They also discuss approaches for integration and unit testing, as well as h...
This is a companion discussion topic for the original entry at https://thoughtbot.com/upcase/videos/speedy-tests
2

In the speedy test video, Joe mentioned Spring to make your tests run faster. He said you need to configure Spring to use it. Any good place where I can find documentation on configuring your Rails application to use Spring?

thanks for the information,

Anthony

3

The documentation on the gem should get you going: GitHub - rails/spring: Rails application preloader

1 Like
4

thanks Ben!

5

How do you get Vim to use the autowrite feature you guys mentioned at 2:45?

I see a few plugins online but am not sure which of those is being used, or if it is something built into Vim.

Thanks for the show!

6

I was wondering this as well.

I notice @benorenstein has some shortcuts in his vimrc file in his dotfiles which will do a :w save before running a spec. I just added something similar (mainly to save myself from repeatedly typing :w. (For example: map <Leader>t :w<cr>:call RunCurrentSpecFile()<CR>)

I also notice @jferris has vim-dispatch set up - is that what you’re using to go directly to the spec failure? I tried using it last week, but it seems like it takes your directly to the failed spec and doesn’t really show you the failed spec output since it opens in a small buffer. Maybe there’s a way to show all of the failed spec output?

I ended up just switching back to a 50/50 vertical split in tmux and using Tslime with vim-rspec to run my specs and output to the non-vim window.

7

I have a quick question about integration tests, since you seem to emphasize cutting these down in your application.

Following the Thoughtbot convention of naming your feature specs (i.e. ROLE_ACTION_spec.rb) I would typically end up with something like user_creates_project_spec.rb.

In addition to this, I may end up with user_updates_project_spec.rb and user_destroys_project_spec.rb.

Are these generally accepted or do you begin to trim down CRUD related integration specs into something like user_manages_project_spec.rb?

Using the example above, typically what I have been doing is going through the steps to create a project (by filling in all the fields etc) and when it comes to updating or destroying a project - instead building them up using FactoryGirl and jumping to specific pages using Clearance e.g. visit edit_user_project_path(user, project, as: user).

Just curious to know what your general approach is here?

Even though you mention it in the video, I feel as if before blocks are not something you reach for immediately. Is that correct?

8

I would generally have many small spec files, so I don’t tend to combine them in this way.

Same!

That’s correct.

1 Like
9

Autowrite is a feature built into Vim. Check out :help 'autowrite' for Vim’s docs on it.

One of the reasons I like dispatch.vim and vim-rspec is that they work well together with autowrite.

I try to avoid thinking in low level actions like “save the current file, run this spec.” Instead, I use autowrite and vim-rspec to do things like “run whatever spec I’m working on and write the necessary files to run it.”

10

In the video you mention 30 seconds for the entire suite to run. We have almost 900 examples and the suite runs in about 55 - 60 seconds. Would you consider that acceptable or should something be done to speed up the suite?