It looks like mock.jar is written by a chef recipe. Is this integration test something that can only be run on chef-manage instances (i.e. not my laptop?)

It seems a little unusual to drop a file in ~ and run it from there; will this work in all of the test running environments that we might care about?

1. The integration test can run on your laptop, if Test Kitchen and Docker are installed locally. I've documented this in cdo-varnish/README.md:

Running Tests

The integration tests run using Test Kitchen.
See test/cookbooks/varnish_test/README.md for more details.

To test the cookbook, first make sure Docker is installed and running locally,
then run:

• chef exec kitchen create to create the machine image
• chef exec kitchen converge to install Chef and converge the cookbook in the
  platform environment
• chef exec kitchen verify to run the integration test suite

I can clarify this documentation to add that test-kitchen, kitchen-docker and berkshelf all need to be available to the Ruby environment (either installed globally via gem install test-kitchen, provided by Bundler through the provided Gemfile after a bundle install via bundle exec kitchen, or provided by ChefDK via chef exec kitchen).

2. This will only work in the provisioned, isolated environment created by Test Kitchen. The actual test_default.rb code is run within the environment via Busser using the busser-minitest runner plugin, after the cookbooks and runlists specified in .kitchen.yml have been applied to the environment. This is all described in the Test Kitchen documentation.

Let me know if you have any suggestions on how to clarify any of these points within the documentation here.

This can be restored if the test is changed to hit CloudFront + Varnish.

This test will succeed on a CloudFront + Varnish request only if we check the Varnish X-Varnish-Cache header for Hit, rather than the CloudFront X-Cache one. To distinguish this test as specifically checking the Varnish cache header, I'll add a new method assert_varnish_cache.

That sounds fine. Or you could have a generic cache method that is happy
if either varnish or cloudfront gets a hit. (That way, if we make
CloudFront smarter down the road, the test doesn't break needlessly, since
we're still getting the desired hit.)

On Thu, Oct 8, 2015 at 4:53 PM, Will Jordan notifications@github.com
wrote:

In
cookbooks/cdo-varnish/test/integration/cloudfront/minitest/test_default.rb
#4440 (comment)
:

• assert_miss response
• assert_equal text_en, last_line(response)

• Ensure that Vary response header is de-normalized

• assert_nil /X-Varnish-Accept-Language/.match(response)
• refute_nil /Accept-Language/.match(response)
• assert_hit proxy_request url, en

• Ensure that language is separately cached

• fr = {'Accept-Language' => 'fr'}
• response = proxy_request url, fr
• assert_miss response
• assert_equal text_fr, last_line(response)
• assert_hit proxy_request url, fr

• Language-header normalization not implemented in CloudFront.

This test will succeed on a CloudFront + Varnish request only if we check
the Varnish X-Varnish-Cache header for Hit, rather than the CloudFront
X-Cache one. To distinguish this test as specifically checking the
Varnish cache header, I'll add a new method assert_varnish_cache.

—
Reply to this email directly or view it on GitHub
https://github.com/code-dot-org/code-dot-org/pull/4440/files#r41584705.