How it checks its work

#After every change

When Synonode changes something you can see, it opens it in a real browser on your computer and uses it the way you would: on a desktop screen and at phone width. It looks at the result, not only at the code. If something's wrong, it goes back and fixes it before telling you.

If your project has its own tests, Synonode runs them too. It checks the code compiles and that there are no type errors.

When it fixes a bug, it adds a test that would have caught it, and proves it on both versions: the test is run on the old code, in a separate copy with the fix left out, and must fail there, then on the new code, where it must pass. A test that passes on the old code too doesn't really test the bug, so Synonode makes it stricter. In a project with git, the old code is the last commit; without git, it's the files as Synonode found them before its change, from the same record Revert uses. A test runs on a separate copy, so your files are never touched. A check in the browser runs on your app itself: for a few seconds the old files are put in place so the app shows the old version, then yours are put back, even if the check fails or is stopped.

#At the end of a build

• It uses the whole app. It goes through the pages, presses the buttons and saves the forms, then reopens the page to see that the data stayed. Your real data is never touched: it uses stand-in data for this.
• It checks everything you asked for. Every option you picked and every detail you gave is held against what was built. Anything missing goes back to the work, not to you.
• It checks the design. Text contrast is measured against WCAG, and the layout, text sizes and tap targets are checked at phone and desktop sizes.
• It checks the words. A spell check runs in the site's own language.

#Tested the way it really happens

A feature is tested where people will use it, not only on one desktop page:

• On a real phone: an iPhone's screen, touch and browser, so a tap is a tap. A menu that works with a mouse but flashes open and shut on a phone is caught.
• With the server's answer made up: an error, an empty list, a slow reply, so every state of the screen is seen.
• Notifications, offline, location, language: permissions given, the connection cut, a place or a language set.
• Leaving and coming back: the tab hidden or the phone locked, then opened again, as with a notification.
• The service worker, the part that makes an app installable and work offline, checked from the inside.
• Over time: what the screen shows every tenth of a second, so a flicker or a spinner that never stops shows up.
• Two people at once: a second visitor or device in its own browser.

What can't run on your computer (a real push from a server, a payment, your own phone) is named in the report as not tested.

#How it reports

The final message is written for you, not for a programmer reviewing the code:

1. What you can do now.
2. How it was checked.
3. Anything it noticed on the way, or a decision you might want to make.

The files that changed are listed under the message, with Revert all if you don't want them. Use /review to have the changes looked over for bugs before you keep them; add what to look at, like /review the checkout flow.