4 ms·
Integration tests become difficult when the output is visual - such as a formatted PDF document or image. The best I've managed to do is store a known-good outp
by hnick 6y ago
Integration tests become difficult when the output is visual - such as a formatted PDF document or image. The best I've managed to do is store a known-good output and regression test against unexpected changes. I work in document composition, and it's very important to our clients that a random business rule does not break the overall look and feel of the document. Unit tests are easy, but don't help with that.
When even minor differences can completely alter text flow you have to basically invert the testing process. You run the program, use your human brain to decide if it looks good, then take that output as the 'good' output for automated testing. That's in contrast to a lot of testing where you can set up the expected results as you write the tests, before the code.
So for me, that definitely falls under the domain of being less suitable for testing. A lot of the usual tricks don't work, and the benefits are less certain.
Since it seems like it'd be very similar in practice, I'm curious how browser devs test the visual aspect (not the parsing or DOM) of browser/CSS rendering - how do they decide the graphical result shown is 'good'?
- qayxc 6y agoFor CSS and the like, A/B-tests are the norm. It's comparing output rendered to bitmap images and verified on a per-pixel basis.