Alex Chaffee's blog
Writing and Testing JavaScript-Heavy Web 2.0 Apps with JSUnit
Alex Chaffee & Edward Hieatt (presented by Alex Chaffee and Brian Takita)
Slideshow link expired. We're hoping to get a fresh copy up soon.
JsUnit
Edward Hieatt (presented by Alex Chaffee)
Slideshow link expired. We're hoping to get a fresh copy up soon.
CI for the Web 2.0 Guy or Gal
Chad Woolley
Full-stack web app testing with Selenium and Rails
Alex Chaffee and Brian Takita
Slideshow link expired. We're hoping to get a fresh copy up soon.
Writing and Testing JavaScript-Heavy Web 2.0 Apps with JSUnit
Alex Chaffee & Edward Hieatt (presented by Alex Chaffee and Brian Takita)
JsUnit
Edward Hieatt (presented by Alex Chaffee)
CI for the Web 2.0 Guy or Gal
Chad Woolley
Full-stack web app testing with Selenium and Rails
Alex Chaffee and Brian Takita
Here's an RSpec trick I discovered yesterday. Sometimes when you're writing a test you want to loop over some precondition data. But if you do a loop inside your test (or spec), then all the cases will be subsumed in a single test method (or "it" block). This means you'll have the following problems:
- The first case to fail will cause the rest of the cases not to run. It'd be nice to see them all in a single test run.
- You won't take advantage of RSpec's cool self-documenting trick of labeling each it block with a full description of the failure, and it'll be harder to debug which case failed.
- If you're calling into Rails (e.g. in a View spec), you'll only be able to call certain methods -- especially
render-- once per test method. That means that you simply can't use a loop inside a method to collapse redundant tests into a single block.
Ruby to the rescue! Instead of looping inside your it block, loop outside your it block.
Wes and Parker pointed us to this article:
Misunderstanding the Law of Demeter by Dan Manges
which is a very nice discussion of the "law" (actually just a suggestion, but a very strong one) that encourages your objects, like small children, not to talk to strangers. Some people seem uneasy with the LoD since it requires them to refactor their objects to have proxy methods all over them. Instead of Paperboy calling customer.wallet.cash you have to put an extra method on Customer -- either cash (attribute delegation -- check out Forwardable in Rails btw) or pay (behavior delegation). But these proxy methods are not clutter, they're the essence of encapsulation. Do not fear encapsulation. Fear is the mind killer.
Anyway, Dan does a great job explaining this concept, until the very end of the article, when he totally chickens out.