Agile, in general, teaches us to adopt practices that add value by giving the team confidence to move forward throughout a project. Lean, specifically, teaches us to remove things that detract value. You seem to have applied both sides of this equation and discovered balance in terms of what to include or exclude in your view specs.

I also think that interaction on teams with developers and designers is a very interesting issue and will become more and more important as larger teams begin to adopt Rails. I’m glad to see that you’re able to use the “pending example” feature so productively in that regard.

Thanks for your efforts and insights.

I have a couple questions about that balance:

How did Aaron know where to add the pending examples? Did you often move them elsewhere when implementing them?

Great write-up! We’ve also seen the same benefits with view testing.

bq. “We told him to ignore the specs in all regards save one. If he was going to add rhtml calls…we asked if he would open up the spec for the view and create a pending statement.”

This is brilliant. We’ve been trying to figure out how to do this on current projects. Fortunately, we’ve been working with a designer that is also competent with Ruby, so he’s been able to do some of the testing, but he’s not very familiar with RSpec, so it would definitely be more valuable for him to just add pending specs.

@craig We didn’t care where he added it as long as it was in the right spec file. From there we usually moved it, and possibly re-worded the spec. A few were promoted to multiple specs (we really try to strive for 1 assertion per test). The most important thing was that we were notified that we needed to add specs.

@zach Yup. I’m big enough to say when I am wrong and that was an instance where by skepticism clouded my thoughts. So in short, sorry for being an ass.