Should you do your full-stack tests with a headless browser? Maybe not.

Posted on by | 8 Replies

Backstory

One job ago I worked on a web product that had a pretty good coverage of Selenium tests. Those tests would spawn a Firefox instance and, as such, tended to be slow. On my quad-core Mac Pro they would clock in at a bit over 25 minutes.

Htmlunit_logoA co-worker of mine saw that this was not ideal, time-wise, and set about fixing it. He pulled out Selenium and plugged-in HtmlUnit (via Celerity/Culerity), updated the tests and — BEHOLD! — the test suite ran in four minutes.

Totally. F’ing. Epic.

Fast-forward to now

Webkit_LogoI’m starting a new web product project and ,naturally, I have some full-stack testing in from the beginning. This time I use capybara-wekbit and all is well. For a while.

Then some warts appear: a case come up where capybara-webkit doesn’t quite render something the way Chrome, Safari,or IE do so although the tests pass, it doesn’t actually work in a real browser.  I spend some serious time reworking the code to make it work properly in capybara-webkit as well as the commodity browsers.

All is good again for a time, but then it happened once more. Again, it’s fixed.

The third time this happens, I stop and think about it:

This stuff MUST work in real browsers, and I usually end up testing that by hand. So what’s the point of running tests through this headless browser? Why am I sinking time in to making this work in a browser that, quite literally, NO ONE will actually use?

The revelation was made: the browser being used is part of the stack in full-stack testing.

And, as such, trying to avoid using those browsers directly is, then, avoiding testing part of your stack. A lot has been said that you should develop on the same system as production: same interpreter, same database, same OS. So why should your tests not follow the same logic? Why test using an abstracted browser that, functionally, is never really used by a human?

Full Stack

Unit-testing is a fair point: when you are unit testing JS, a headless browser is probably a good thing to use. It will be faster and (assuming ECMA compliance) just as good as a real browser. But unit-testing is not full-stack testing.

This was a turning point for me. Before that, I saw using Selenium as using a crutch. Now I see that using Selenium is the whole point. You are not just testing your code, you are also testing how your code interacts with the browser. To wit, the browser is in actuality part of your product.

Ok, so, fact: doing Selenium tests with one browser is slow. Doing then with multiple browsers is even slower. But the solution to this problem is not to remove the browser from the equation, is is to make the browser a manageable part of the equation. Farming, parallelism, concurrency, those are all viable ways to make the speed issue more manageable. But removing the browsers from the testing process is not.

“Element is not currently visible and so may not be interacted with” and iFrames

Posted on by | Leave a reply

Suppose you’re using the following command to interact with an iframe within capybara:

page.driver.browser.switch_to.frame(‘iframe’)

Sometimes it works, but often you get en error like:

Element is not currently visible and so may not be interacted with

You may be falling prey the retry methods built in to capybara. See, capybara is waiting for something to appear in the dom and keeps retrying failing code until it does.

But what you did, by changing scope with “#swich_to” is made it so a previous passing command is now failing. Technically, you’ve made only what is in the iframe visible to capybara, so when the retry happens, things that were previously there are now not visible; they are still in the DOM, but not in current scope, hence “not visible”.

Try this. In a “background” or “before(:each)” before the test in question:

background { @window_handle = page.driver.browser.window_handle }

..and then, before your assertions:

page.driver.browser.switch_to.window(@window_handle)

That will ensure proper DOM scope on the retries.

Twitter Pair Programming Bot

Posted on by | Leave a reply

Apologies to Jim Weirich, creator of the original Pair Programming Bot. I copied him to make this.

The command list fot the Twitter Pair Programming Bot:

  • hello : Say hello you dolt, it’s good manners.
  • start FEATURE_NAME : start a new feature.
  • yes, /^yes/ : answer in the affirmative. (any response starting with the word “yes” is accepted.)
  • no, /^no/ : answer in the negative. (any response starting with the word “no” is accepted.)
  • list : show what features you’ve worked on together.
  • where : where were you in the current feature?
  • what : what feature were you working on?
  • finish : prematurely mark feature as finished.
  • spoon : asking the bot to spoon with you will have it follow you. You can then talk to it via direct message. You MUST follow it back so it can DM replies.

How to sound like a programmer with three easy phrases

Posted on by | 1 Reply
Typical Hipster Office
Typical Hipster Office

Have you ever been to one of those fancy parties those Dot-Com people throw? You know the ones: It’s at their office in some scary part of SoMa. The building used to be a wool cannery, but now that the company has 80 dicktillion bucks they’ve installed a skateboard ramp and drive-thru Kombucha stand.

Typical Hipsters
Typical Hipsters

You’re surrounded by 30-something single men who are trying hard to look like 20-something androgynous women. They’re all wearing wool caps and their younger sisters’ jeans, sipping gold-plated champagne and complaining about how it’s just not as good as that PBR that had last night at that one bar in the Tenderloin.

They’re all talking about computer programming. You’re not a programmer.

But you can fake it with these three simple phrases.

 

Continue reading →

I invented Twitter. Maybe you did, too.

Posted on by | 1 Reply

Back in 2005 I had this idea for a web site. Here’s how it was supposed to work: You would use your mobile phone to send messages to a web site that would then re-broadcast that message to your “friends”. You could also use small desktop app. You’d “friend” people, and then the site would send you anything they posted.
Fake Twitter?
Sound familiar? For the uninitiated, that’s basically Twitter. But about two years early.

I started work on it, but never finished it because I started to feel like there was no market for something like that. I got sidetracked and let it die.

Then, around 2007, I heard about this “tweet” thing and I was like:

Fuck, really? What a rip-off of my idea! Twitter STOLE my idea!

Continue reading →

Ruby for the Perl tourist: Part 2, Object and Symbols

Posted on by | 4 Replies

Ruby is from objects, Perl is from procedures

Perl has had objects for quite a while now, decades even, but you can’t get away from the fact that OO is really just a bag-on-the-side of Perl 5.  This can be a Good Thing sometimes, actually, because it means that well-written code can be used objectively or functionally.

Still, though, Perl 5 is fundamentally not OO at it’s core and all the magic exists in bless().  Ruby (and many others, too many to mention) are object oriented from the ground up.  But what does that really mean?

Continue reading →

Ruby for the Perl tourist: Part 1, Syntax, Grammer, Parenthesis are for the weak

Posted on by | Leave a reply

This is the first part of what I hope will be a pretty useful set of tutorials for those moving from the world of Perl in to Ruby. For the overview of topic I hope to cover in this series you can go back and look at the “Overview” page. In this first part I want first to talk about how Perl and Ruby are similar and then go over some of the most visible differences.

Continue reading →

Ruby for the Perl tourist: Overview

Posted on by | Leave a reply

I originally gave a presentation with this same title at the February 2012 ut.rb meeting.  Although it was focused at the Perl programmers that were present at that meeting it was so well received I’ve decided to spend more time on it an develop it in to a series of blog posts.

Of course this is meant to give Perl programmers a foothold in a new language but it is also useful for anyone coming in to the language from somewhere else.

My Perl credentials

I started developing in Perl in 2000 and was a full-time Perlista from 2000-’07 using versions 5.005 to 5.6, but I’ve never used the Perl 6 series.  My first gig was doing financial code for a credit-card processing company, then I moved on to start a web site (Quizilla.com) that eventually went to many tens-of-millions of daily page views on Perl code I wrote.

Overview of what’s on tap

In this series I plan on covering:

  • Part 1: basic similarities and shared conventions. Differences between use of semicolons, and parenthesis.
  • Part 2: Bagging on Perl’s OO system.  Objects and methods under Ruby.  Symbols.
  • Part 3: Perl sigils counterparts in Ruby.  New meaning of $, @ and @@.  Constants in Ruby.
  • Part 4: String interpolation, deliberate/implicit returns on methods.
  • Part 5: Bang (!) and Boolean (?) methods.
  • Part 6: blocks (very basically).
  • Part 7: bonus Rails-specific content: method_missing() and “magic methods”.

NETWORK_ERR: XmlHttpRequest Exception 101 on PhoneGap

Posted on by | Leave a reply

Check to see that you’re not trying to do a synchronous call cross-site. And if you’re doing PhoneGap chances are the majority of calls you’re doing are cross-site.

$.ajax({
...
"async": false,
...
});

..probably needs to be changed to “true” or removed altogether. If you really need cross-site async JS you may look in to <a href=”http://code.google.com/p/jquery-jsonp/”>Google JSONP</a>.