#1127

I'd be +1 permitting controller tests for:

• API/structured responses (xml, json, etc)
• Security testing (ok vs 403 responses)

View tests at the page level would still be better as features (When I view a page, I see an X, click a Y)

View tests at the javascript component level or helper/widget level (Graph widget X, given this data, does Y, Z)

Outcome of this would be to add it to the coding style wiki and amend the various deprecation notices

Good talk on it via https://www.youtube.com/watch?v=MkPHntWZAPc - specifically using features for 'end to end' style tests on the absolute critical path, vs the risk of flakey behaviour (which has caused us much fun with PRs).

This concept ("The test pyramid") is useful for assessing what is better tested where

If we end up with lots of tests, the above talk introduces a companion concept, the "PUMA" test:
http://www.bbc.co.uk/blogs/internet/entries/ba0c030e-d031-4ab6-8ba6-3afe41807b55

The less a test meets that criteria, the more worth pushing it down the testing pyramid

I started writing controller specs for gardens last night.

I tested for users editing other people's gardens, deleting other people's gardens etc.

I came to the conclusion, we need to have the successful normal edits in the controller spec too. I need to verify we are calling the controller correctly and able to get a success, before then changing owner_ids and expecting to be blocked. Otherwise we may get a pass on "when user tries to edit another member's planting they are refused" only because we called the controller wrong.