You can run scripted browser tests against a Turnkey application with Selenium and use a slave-connected test to verify that committed master changes reach the slave.
Choose the test target
A standard slave receives committed update packages from the master through MDrivenServerSynk. A test that writes data and then reads through a slave must allow for the time required for the slave to collect and apply the committed update package.
| Test purpose | Connect the test to | What to verify |
|---|---|---|
| Create or change data | Master | The change is committed on the master. |
| Verify replicated data | Slave | The slave eventually shows the committed master change. |
| Verify a save through a ReadOnlySlave | ReadOnlySlave | The save is routed to the master, then returns to the slave through MDrivenServerSynk.
|
For example, a browser test can change a Company's name through a master-connected application, save it, and then refresh the same Company through a slave-connected application until the new name is visible. Do not treat an immediate slave read after a master save as a replication failure: the slave can temporarily show the previous value.
Configure the master and slave before running the tests. The master must be in Master mode and have the MDrivenServerSynk table. Configure the slave to contact the master, and use Get model from master for its initial model. See Documentation:Slave and History Server for the server configuration and HowTos:Test Slave Server Setup for a manual replication check.
Create and run Selenium tests
Selenium runs scripted web tests against a Turnkey application. Use Selenium IDE in a browser to create, edit, and run a test project, then save the project files locally.
- Record or create a test that opens the Turnkey application, locates a Company, changes its name, and saves it.
- Create a second test that opens the slave-connected application and refreshes the same Company.
- Run the tests first from Selenium IDE to confirm that the application URLs and test data are correct.
- Install Node.js and install the Selenium command-line runner.
- From the directory containing the
.sidetest project, run the Selenium command-line runner against the project.
A command-line test run is suitable for a CI/CD job because the runner executes the saved .side project from the command line. The job must make the Turnkey application, MDrivenServer master, and any slave used by the tests reachable from the machine that runs the command.
Run tests on Selenium Grid
Use Selenium Grid when you need to run saved browser tests outside your desktop browser or run several tests concurrently. HowTos:Selenium Testing describes a Windows setup using WSL2, Docker Desktop, and the SeleniumHQ Docker images.
Create a .side.yml file beside the .side project to direct the command-line runner to Grid:
capabilities:
browserName: "chrome"
se:recordVideo: "true"
se:screenResolution: "1920x1080"
server: "http://<grid-host>:<port>/wd/hub"
The browser name is case-sensitive. Use chrome, not Chrome. With se:recordVideo: "true", Grid stores a video.mp4 file for each test run in its assets output.
To request five concurrent executions, run:
selenium-side-runner -w 5 .\MyTest.side
For example, duplicate a Company-view test and add both tests to the default test suite so that the runner can schedule them concurrently.
Handle replicated-data timing
A slave continuously polls the master for changes. Given time and working connectivity, it reaches the same content as the master. Build this expected delay into a replication assertion: after the master test saves Company.Name, the slave test refreshes and checks for the committed name.
If a ReadOnlySlave cannot reach the master, users cannot save through that slave and it does not receive updated data. A failed save or a slave that never receives a change should therefore be investigated as connectivity or master/slave configuration before treating it as a browser-test failure.
Test-data lifecycle
Use a dedicated test environment and identify the Company data that each test will change before running the suite. A slave is kept current from master commit packages. This means that test data created on the master can become visible on the slave.
The documented slave setup does not define an automated mechanism for seeding a test database, resetting it between runs, or deleting test data after a run. Define those operations for the database platform and CI/CD environment before enabling repeated or parallel test runs.