Unit testing of custom VCL

Comments

2 comments

  • amcelwee

    I don't have an answer for you, but I'm in the same boat as you right now and am considering moving back to vanilla vcl for all our config. The enhanced cookie manipulation and querystring modules are really nice, but they obviously come at the cost of testability for what needs to be a bulletproof component of our infrastructure.

    My current (less than ideal) progress is that I'm splitting all of our vcl into very small, logical chunks, and based on whether they use any fastly custom features, will either be tested using varnishtest or omitted and only tested as part of an integrated system with a real origin to serve requests on a separate, non-production domain served by fastly. There's certainly value in the large-scale, end-to-end integration test, but I haven't found a way to completely fill the unit-testing gap for the individual chunks.

  • Håkon Erichsen

    We've also bumped into this problem, and have started out with integration tests: Our automation sets up a test service, points it at a test environment, and runs all the tests, which is mostly sending/getting requests and looking at headers and status codes. For some of the tests, we're currently looking at using https://httpbin.org/ (or a private instance of it) as an origin, which seems pretty powerful to make narrower tests.

Please sign in to leave a comment.