However, there is more more to this then verifying it renders. For that, I still need to be able to see it in a browser right in front of me.
For me, the two minute setup time for this is well worth.
Thanks for the suggestion/comment.
How do you mean?
Again, this could all be done on a dedicated test/staging server, but the cost of doing it locally is virtually free, so why not?
I should preface it by saying I'm working with a team of about 10 developers. For every developer to have to the software working on their local machine, it's a burden.
Our unit/functional tests run clean when SSL is stubbed out from client requests. We use webmock (https://github.com/bblimke/webmock) to mock 3rd party integrations. Upon deploy to staging, integration tests (Selenium) sweep through.
Our monitoring software ensures the app and its 3rd party services are responding to those integration points.
So yeah, developing by yourself, it's ok-ish. Though I still prefer having infrastructure be predictable. Mocking the SSL configuration through a reverse proxy feels brittle to me...it usually isn't how production is configured.
I guess another way of putting it -- I'd rather not inspect to make sure the app and its components behave over SSL. I'd rather it not work. Fail fast as they say.
I should draft up our approach and clarify the points. Maybe this weekend.