My name is Will, I'm 30 years old, and I'm a Pivot. In my three year tenure here at Pivotal Labs, I've found that it may be easy to see the parts that make us successful consultants, but that forrest is hard to see for all the trees. Everything from breakfast to keybindings plays a part in making us one of the top software consultancies and the greatest place I have ever worked.
OAuth providers like LinkedIn often pop-up in a new browser window rather than in Javascript so that the user entering their credentials can see the location bar to be sure they are not being phished by the website requesting their credentials. This is great for security, but not so great for Cucumber testing.
features/signup.feature
Scenario: Sign Up with LinkedIn
When I go to the home page
And I follow "Sign Up"
And I grant LinkedIn access
Then I should be on the new user page
My application has a hyperlink that opens the OAuth login on the OAuth provider's website in a new window. Let's presume the simple matter of wiring this up is already coded in my view.
Testing this with Cucumber requires telling the Selenium web driver to interact with the new popup window. We can do this using page.driver.browser.window_handles to find the newest window handle and scoping out actions to that window.
features/support/signup_steps.rb
When /^I grant LinkedIn access$/ do
begin
main, popup = page.driver.browser.window_handles
within_window(popup) do
fill_in("Email", :with => "newlee@pivotallabs.com")
fill_in("Password", :with => "password")
click_on("Ok, I'll Allow It")
end
rescue
end
end
And that's it!
Keep in mind that if you use this test as-is, you will be hitting LinkedIn on the real Internet. This is great if you want a test that will always verify the real API, but not so good for CI, since it is Internet connection-dependent and slow. Consider using something like VCR or Artifice to stub out your service calls.
Android Activity classes can become gigantic and unwieldy if you're not careful. Testing complex Activities requires complex setup. To reduce that pain we try our best to keep the Activity lean. This means getting logic out of the Activity. One technique we use is to create custom views that we can test in isolation.
Visiting Olin
Today, Josh Knowles, Grant Hutchins, and I visited Franklin W. Olin College of Engineering in Needham, MA to talk to Prof. Mark L. Chang's amazing new dotcom course. We talked about agile development, and more specifically how Pivotal does agile and why. We went through an example of test-driven development for a simple Rails app, and had a miniature inception for a fictitious product.
Some students asked for some resources, particularly for documentation, so I put together a collection of resources for anyone looking to pick up agile, TDD and Ruby on Rails. This is intentionally not an exhaustive list. I wanted to include the bare minimum for getting started on each topic as a jumping off point and include further references at the end.
Recently, Martin Odersky and David Pollak visited Pivotal Labs to show off Scala and its Lift web framework. I have an ongoing interest in concurrent programming and this resparked my interest in Scala and its Actors, a library that leverages the Erlang style concurrency model but with a (relatively) more familiar JVM language. I began spiking on a project with Actors some time ago but hit several issues that made me really want to test-drive the project to both drive out better design, and hopefully eliminate some of these bugs in a more productive manner.
After some effort reading documentation about both ScalaTest and Scala's Actors, and wrangling with the compiler for a while, here is where I am so far.
The test for a very simple Square class that accepts three messages, then returns the maximum.
package test
import org.scalatest._
import matchers.MustMatchers
import main.Square
class SquareSpec extends Spec with MustMatchers {
describe("Square") {
it("returns the max of 3 messages received") {
val timeout = 500
val square = new Square
square ! 1
square ! 3
(square !? (timeout, 2)).get must equal(3)
}
}
}
Here is the implementation.
package main
import scala.actors.Actor
import scala.actors.Actor._
class Square extends Actor {
var numMessagesReceived = 0
var maxMessageReceived = Integer.MIN_VALUE
this.start
def act() {
loop {
react {
case msg : Int => replyWhenNecessary(msg)
}
}
}
def replyWhenNecessary(msg : Int) {
println(msg)
maxMessageReceived = if(maxMessageReceived > msg) {maxMessageReceived} else {msg}
numMessagesReceived += 1
if(numMessagesReceived == 3) {
reply(maxMessageReceived)
exit
}
}
}
Things I learned:
Scala
- Scala's classes don't call out the main constructor, you just dump the class variables in parentheses after the class name and constructor code inside the body of the class
Actors
- You can use the method
!?(timeout, message)in place of!(message)to synchronously, and with a timeout, get a return message from the actor. The actor must reply though. The timeout is great for testing, often you'll have an actor in an infinite loop and your test won't complete instead of failing nicely.
ScalaTest
- ScalaTest has several flavors of test, but the one that most Rubyists will appreciate is having your test class extend
Specas it is most similar to RSpec.
General
- IntelliJ Community Edition with the Scala plugin is pretty awesome.
Hopefully I'll have more later as I continue my effort to learn how to test concurrent programming.