Don’t reduce dispatcher testing to an afterthought
Frankly speaking, dispatcher usually does not receive much attention when it comes to testing. In most cases configuration updates get inspected only on the go without any regression tests being triggered alongside.
Neglected dispatcher may lead to application issues that often slip through unnoticed across lower level environments and surface right after production deployment.
Overlooked dispatcher testing doesn’t come out of nowhere - it’s neither straightforward nor easy to implement a reliable test suite for it. Moreover, dispatcher is often not verbose enough and all its surroundings would have to be mocked out to test it in isolation.
This talk will describe various techniques (man-in-the-middle proxying, mocking strategies, configuration tricks, CI/CD pipeline examples, etc) to let you test and promote your dispatcher config with confidence.
Henry Kuijpers
Are you also thinking of setting up Dispatcher /filter testing? To for example check the security checklist, the known vulnerable URLs, etc. etc.?
jwadolowski
Small addition to what I already answered on stage - when testing filters, allowed query params, etc you can inspect one of these special headers I mentioned during my talk - you're gonna find "not cacheable because of query param X" or "blocked by filter Y" information there.
Tomasz S
Do you think it would be better to let CDN deal with gzip, etags etc? Is dispatcher the best place for it? I guess you wanted it there to optimize the traffic between cdn and apache as well?
Konrad Windszus
AFAIK Fastly generates ETags by default for AEMaaCS if they are missing from the origin response
Robin
Wouldn't it be easier if Adobe just clear the cache from the Cloud Manager Pipeline (after running the functional tests) and then start the cache-warmup?
jwadolowski
Warmup service pre-populates dispatcher cache with objects upon instance start and functional tests get started afterwards, so that'd defeat the purpose of the warmup. Adobe's working on an alternative approach to functional test execution (these .net domains won't be used at all).
Henry Kuijpers
What is that default domain / where can we find that setting (OSGi console)?
Andres Bott
reach out to me, i can give you some details
Andres Bott
for the time being, please also do not block the .net domains in dispatcher config
Alexander Berndt
Did I understand correctly, that your workflow was more: Detect Incident, analyze it, reproduce it in this clean test-environment, fix it, and eventually keep the tests in the CI pipeline. Otherwise I would find it hard to identify test cases upfront. In real life problems are way more complicated than someone could imagine.
jwadolowski
All these incidents I mentioned resulted in Apache config adjustments/fixes and effectively were the main driver towards dispatcher testing. Initially we focused on these burning cases, but at the end of the day all existing Apache/dispatcher features were retrospectively covered with tests. I personally don't find it that hard to identify test cases, but your milage may vary (it boils down to how you manage your dispatcher configuration).
Henry Kuijpers
Are you thinking of open-sourcing this as a full-fledged testing library for everyone to use?