MVP E2E integration testing === **This plan is based on something we can begin to build immediately** ## Busines Value Alastair Ong wrote: >"HoloCentral business value in no particular order: An app provider can successfully register a hApp for hosting (incl. domain name) and be confident that it works and is accessible An end user can access a hApp hosted on HPOS via a URL A host's HoloFuel account is automatically credited for hosting work done Holo automatically receives transaction fees" In order to achieve an automated E2E test of the above defined business value, the following phases are proposed ### Phase 1 using https://nixos.org/nixos/manual/index.html#sec-nixos-tests as a framework, and running tests in our existing hydra server environment: 1. achieve dockerization of zato and kong so that they may be run in this environment 2. architect *N* virtualmachines that represent Holoport nodes with installed software before E2E test these nodes will be initialized with holo init process. This means that these nodes will have generated HC keys, written out to kong, cloudflare DNS etc the entire init process on the proper network 3. architect (these are configured as either nixos VM, or docker containers running on nixos vm). In either case these can be images vs build from scratch machines each time. : * 1 node for kong, * 1 for zato, and * 1 for database for kong/zato, * 1 for redis for zato, * 1 for haproxy for zato 5. trigger this test after appropriate unit and other component and OS tests in our pipeline ### Phase 2 In this phase we create the clients that can drive a scripted UI process across the deployed components in the e2e tests from step one, and we create the failures if tests do not pass Candidates for this can includeframeworks that allow us to script users driving a system from a UI. Options to investigate: * ghostscript, * selenium, * https://ghostinspector.com (selenium compatible) * cypress, and * other The outcome is that we choose the framework, and implement the tests via scripting in nixos-test ### Phase 3 We refine our ui driven tests to include security, accessibility, and a limited scope of browser and device support, and a way to verify all of the above