Unit testing of custom VCL


#1

Is it possible to run unit tests for a custom uploaded VCL file?

I need to be able to run tests against our custom VCL before uploading it to Fastly. The Fastly docs suggest that to test custom VCL we should upload the VCL to a test account, and test against a testing environment before copying the VCL to production (https://docs.fastly.com/guides/vcl/previewing-and-testing-vcl-before-activating-it). Manual testing or testing the entire testing environment with an integration testing tool such as Selenium isn’t really sufficient - we think that we should be able to unit test our VCL code.

Varnish comes with it’s own testing tool called varnishtest. (See https://www.smashingmagazine.com/2016/05/five-simple-steps-test-varnish-cache-deployment-varnishtest/). I have tried using this to test our Fastly validated and working Fastly VCL, but have obviously found that there are extensions (https://docs.fastly.com/guides/vcl/guide-to-vcl#fastly-39-s-vcl-extensions) that aren’t compatible with the VCC compiler, even when using varnish 2.1, which is the version that the Fastly docs say their syntax is compatible with (https://docs.fastly.com/guides/vcl/guide-to-vcl).

Does Fastly provide a varnishtest tool or similar compatible with Fastly Varnish, or does anyone know of another solution to this?


#2

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.


#3

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.