Implement Percy for visual review/testing of participation client

[patcon]

Re-ticketed from Gitter chat: https://gitter.im/pol-is/polisDeployment?at=5febe53e2084ee4b787de56a

https://percy.io/

[metasoarous]

Hey Pat; Can you please comment further on how this relates to our Cypress setup? I thought Cypress was already doing visual integration testing? Am I misunderstanding or does this do something different/more specific? Thanks.

[patcon]

Good call. Cypress is e2e testing, which tests functionality based on dom selectors, telling something about whether features broke.

Visual testing is to catch when CSS changes and layouts move around.

Different use-cases, and both healthy practices, though e2e testing is def more important.

So it's feature testing vs layout testing :)

EDIT: A tool like cypress (or puppeteer or webdriver etc) is used to navigate the app and take screenshots, which are used by something like percy for visual diffing. There's a cypress plugin: https://docs.percy.io/docs/cypress

[metasoarous]

I see; Thanks for the clarification. That makes sense.

I think this makes sense for the participation interface, but is probably overkill for admin & report.

[patcon]

Agreed, no prob

Related to visual testing of client-participation viz: In the kitchensink e2e test, we fake enough votes to render the viz. I recall that sometimes the hulls are drawn differently, even though the votes registered should * always be the same. If the test waits for math component to catch up on processing, should the the hulls be drawn consistently from one test conversation to the next? Or might there be slight variations?

* ^{It's possible that with the speed of the test, that not all POST requests are registered as votes somehow, which could also explain the variation in hull appearance}