4 ms·
If this was only about code, I would agree with you. However, there is more more to this then verifying it renders. For that, I still need to be able to see it
by swatermasysk 15y ago
If this was only about code, I would agree with you.
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.
- gry 15y ago> However, there is more more to this then verifying it renders. How do you mean?
- swatermasysk 15y agoVerifying scripts work properly under SSL, verifying the experience between other 3rd party services (such as payments), etc. 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?
- gry 15y agoI follow. 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 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.