As it turns out, in Rails 3.x, webrat and cucumber don’t play along so well. You start getting horribly annoying, and difficult to solve error messages. The solution in that link is to change the testing method from Rails to Rack. That works, for things like visiting pages, but it broke all of my API tests, where I verify the response code of the body and the JSON that I get back.

I looked into upgrading cucumber-rails, and apparently they recommend using Capybara instead of webrat for Rails 3. So I make the necessary changes. Unfortunately Capybara only has a get method. You can only visit pages. Any posts should be exercised by the web forms. This is far less than useful. It has proven to be a huge pain the butt. Hours of trying to find how people do this to no avail. Until I find an obscure answer, at the bottom of a StackOverflow posting.

That code on github is the key to testing APIs. It appears to use some of the more internal guts of the Capybara page drivers to accomplish it’s goal. Works for me.

I am surprised to see that there are few integration test frameworks that support this kind of web service test. Especially since where I work, this is what we build. Having Cucumber features describing those API calls makes everyone’s job easier. I find it unfortunate that it seems to be somewhat ignored by the testing community. Hopefully this will contain the necessary words for other people that are searching for the same thing I spent hours searching for, and will find it in far less time.

 

I forked an xmpp4-simple gem that had some issues, and figured out which they were, and then committed the fixes in my own github repo.

It appears that the original gem is unmaintained, and so I just forked it and updated some parts.

 

MINECRAFT!

Someone has done no small amount of determining what the code within the minecraft_server.jar does and how you can inject hooks into it. I have forked that git repository and am trying to organize it a bit better. Possibly make it truly into just a plugin framework and nothing else.

I’m hoping that this will be useful to others and that it all won’t horribly break when the server is changed on the 31st. Otherwise, all the really awesome administrative abilities will be horribly broken. Another really awesome thing would be if Notch were to have a plugin API ready to go. Perhaps based on the work that the community is doing.

 

Was harder than it should’ve been. I got annoyed.

You need to install openssl-devel, zlib-devel, bison, gcc, make, patch, tar, and maybe gcc-c++ (although I don’t think this one is needed).

Go get the latest ruby 1.9 source, as of this writing 1.9-p378, and extract it somewhere. Then go get the patches on this bug, at the specific comment. You will need to apply at least the openssl-build-fix patch, since fedora uses openssl 1.0 and it’s not yet into ruby 1.9. Then follow your typical ./cofnigure, make, and make install stuff. I installed mine into a prefix of /opt/ruby so that it wouldn’t affect any fedora ruby stuff that it might want. I then added ruby’s path to the end of my user’s PATH variable.

That’ll get you a working ruby 1.9 in Fedora.

 

http://www.vim.org/scripts/script.php?script_id=1567

Woot.

EDIT:

Man, this guy has all sorts of good stuff: http://www.vim.org/account/profile.php?user_id=9012

cucumber, rails, ruby, git-vim integration. VIM FTW!

© 2011 Shlrm.org Blag Suffusion theme by Sayontan Sinha