Linux Tage 2013 in Berlin is the biggest Linux Conference in Germany. It goes from Wednesday to Saturday. There are all day long sessions & tech talks. And of course a big exhibition hall, where you can meet some of the vendors. It is a place there .com meets .org.
I have been there today and will be there tomorrow and on Saturday. You can find me at the Yunicon stand in the exhibition hall. Yunicon is an awesome private cloud provider from Berlin. They have the coolest stand in the exhibition hall because they offer free cocktails!
I am doing every day at 15:30 a talk about Continuous Updating with VersionEye.
If you want to learn something about Continuous Updating or VersionEye, join the talk. Grab a free cocktail and ask me your questions. I am happy to answer them.
VersionEye has now new dependency badges for Java, Ruby, PHP and Node.JS. You will find them on every package page. They look like this.
They badges are showing you immediately if the dependencies of a software library are up-to-date, out-of-date or unknown. By clicking on the badges a popup will appear with code snippets for the most used markup languages. Just use copy and pate to add the badges to your GitHub Readme.md or another HTML page.
The badges are also available for your VersionEye projects, if they are public.
A project is up-to-date if all his dependencies are up-to-date.
At VersionEye we provide a login with your GitHub Account. Initially we implemented the GitHub login with the “repo” scope. That means that you give VersionEye read and write access to ALL your repositories, even your private ones. Many people asked me why VersionEye needs read and write access to private repositories. Well. VersionEye don’t need write access to your repositories because VersionEye never will change your source code. But currently the GitHub API doesn’t provide a “read-only” scope for private repositories. I talked to the GitHub guys at the GitMerge Conf. in Berlin and I know they are working on more scopes for the GitHub API.
The 2nd question is why VersionEye needs read access to private repositories. Well. We just need that if you want that we monitor your private Repositories.
Because so many people complaint about this scope, we did some refactoring. If you now login in via GitHub, VersionEye will only ask for read access to your public repositories.
If you want to create a new project at VersionEye, we will only fetch your public repositories.
But if you want that VersionEye is monitoring your private repositories, you can afterwards grand VersionEye access to your private repositories. You just have to click the link “Grand access to private repositories” in the GitHub tab. Than this dialog will appear.
And again. VersionEye will never do write operations on your repositories. We use that scope only for reading and monitoring your private repositories.
In the settings area you can click on the link “Connect”, to see your connections to other social networks. Here we display you also the GitHub API scope we have for your account.
You can every time use the “disconnect” link. That will delete the GitHub token for your Account in the VersionEye database.
You can just keep writing your acceptance tests as usual with RSpec and Capybara. Here is a small example.
describe "Empty Payment History", :js => true do
it "shows correct message when there's no history" do
have_css "#payment_history", text: "You dont have any Payment history"
This test is sending a request to “/settings/payments” and is testing if on the page the CSS class “payment_history” occurs. Pretty easy. This you could also do with WebRat. But the magic is in the first line. “:js => true” that tells Capybara that it should execute the test with the selenium-webdriver. That will basically start your browser (Firefox) and you can see how the test gets executed. This is not possible with WebRat.
It’s just getting a little bit tricky if you do a lot of AJAX requests on the page. In the Capybara documentation they write that you should use the “find” methods, because they wait until an element appears on the page. That didn’t worked out for me. The test always failed. Somebody on Stackoverflow wrote that this construct would work for AJAX pages.
page.all('a', :text => 'View receipt')
And he was right! This test always succeeded. ALWAYS! Even if the test was completely wrong! Yeah. Very funny! *LOL* Seems like a bug. I did a little bit more research and finally I found a solution which worked correctly.
using_wait_time 10 do
page.should have_content("View receipt")
With “using_wait_time” you can force Selenium to wait for a couple seconds, until the AJAX requests are done. That finally worked out and the tests are working now correctly.
I one of my applications I had a bunch of tests written with RSpec and Webrat. Unfortunately it seems that Webrat is not longer maintained actively anymore. That’s why it is a good decision to move to Capybara, an active Test Framework for Ruby.
The Migration was so far pretty smooth. Most time it was a simple replacement of code. Most time I had to replace something like this:
With this :
Otherwise assertions like this caused problems:
response.status.should == 401
That worked again as soon I wrote it like this here:
2 times I got the error message that response is nil. That I could resolve by assigning it explicitly.