![]() * and generates Paparazzi screenshot tests for them. * Finds all files in the components module which have Compose previews To do this we created a Kotlin program with a main function and used another library, also from Square, KotlinPoet ( ) to generate the code.ĭisclaimer: This code is still quite rough, but you get the idea and it does what we needed. Find every file that has at least one annotation.Because of this, all our snapshot tests look pretty much the same, We always write one snapshot test per annotation. This would be quite boring and repetitive, so we decided to try to generate them instead of writing them manually. To really compare Paparazzi with Shot and see if it solved our problems, we had to rewrite all our snapshot tests. This works just as well with a full width. The main point is to compare the current situation to the previously recorded snapshot and see that there are no unintended changes. Though it would be nicer without the full width, this is not a big problem. There is no similar trick for the width (that I know of, please let me know if you know one!), so we always get the full width of the device which leads to some screenshots looking like this (if you click it you see the full device width): The screenHeight = 1 and renderingMode = V_SCROLL is a trick to get the minimum height needed to take a screenshot of the Composable. Unfortunately Paparazzi does not (yet) support taking a screenshot with the exact size of the Composable: A Paparazzi test looks something like this:Įnter fullscreen mode Exit fullscreen modeĪgain like Shot, Paparazzi has one gradle task for recording: ![]() ![]() Paparazzi, like Shot, is quite easy to set up. This all changed recently in the 1.0.0 release. Not having to deal with the emulator is a massive time saver.īack when we initially implemented our snapshot tests, Paparazzi was not an option because it did not support Compose. Paparazzi is a library which can render your application screens without a physical device or emulator. Someone has to take the time to check the Teams channel every morning and fix the tests.You might discover failing tests too late - even after the changed code has been released.You are no longer "forced" to fix your failing snapshot tests before you merge.Instead we have a nightly job that runs the snapshot tests and reports to our Teams channel if any of them fail. This is too long to include it in our continuous integration pipeline which runs on every pull request. Starting an actual emulator and running the tests on this emulator in our CI environment takes around 30 minutes. One problem with these tests is they take too long to run. I previously wrote about snapshot testing Compose with Shot here: Instead of generating code with KotlinPoet, it automatically runs Paparazzi tests for each Compose Preview. Since writing this article I've moved on to yet another improved way of doing this.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |