Imagine we have a reducer to control a list of items:
function listOfItems(state: Array<Object> = [], action: Object = {}): Array<Object> {
switch(action.type) {
case 'SHOW_ALL_ITEMS':
return action.data.items
default:
# Ajax testing with ruby and capybara | |
# | |
# Add this to spec/support | |
# | |
# When a link or button starts an ajax request, instead of use Capybara | |
# click_link, click_button and click_link_or_button methods use click_ajax_link, | |
# click_ajax_button and click_ajax_link_or_button methods. You can still use | |
# capybara methods and right after it, call wait_for_ajax method. | |
# | |
# This methods will wait until Capybara.default_max_wait_time for the ajax request |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft
, elem.offsetTop
, elem.offsetWidth
, elem.offsetHeight
, elem.offsetParent
$ sudo apt-get install chromium-chromedriver | |
$ sudo ln -s /usr/lib/chromium-browser/chromedriver /usr/bin/chromedriver |
# Start the old vagrant | |
$ vagrant init centos-6.3 | |
$ vagrant up | |
# You should see a message like: | |
# [default] The guest additions on this VM do not match the install version of | |
# VirtualBox! This may cause things such as forwarded ports, shared | |
# folders, and more to not work properly. If any of those things fail on | |
# this machine, please update the guest additions and repackage the | |
# box. |
HTTParty.get "http://localhost:3000/teams.json", :headers=>{"Authorization"=>"Token token=\"a8d8ce14d2402a2e1912c25f39df770b\""} |
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.