index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Fábio Carballo</title><link>https://fabiocarballo.github.io/</link><description>Recent content on Fábio Carballo</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>© {year}</copyright><lastBuildDate>Sat, 06 Nov 2021 17:44:01 +0100</lastBuildDate><atom:link href="https://fabiocarballo.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>Multi-Theme Screenshot Tests in Jetpack Compose</title><link>https://fabiocarballo.github.io/blog/multi_theme_screenshots_tests_in_compose/</link><pubDate>Sat, 06 Nov 2021 17:44:01 +0100</pubDate><guid>https://fabiocarballo.github.io/blog/multi_theme_screenshots_tests_in_compose/</guid><description>I have been working a lot with a design system, and one of the recent challenges was to add support to screenshot testing while making it easy to scale for several different themes. In my vision, we would be able only to write one single test, but automatically generate the screenshots for all the themes in one single run.
Meanwhile, I reached a solution that can be seen in this sample project created for this purpose.</description></item><item><title>The relationship between bad domain modeling and Hyrum's Law</title><link>https://fabiocarballo.github.io/blog/the_dangers_of_hyrum_law_in_domain_modelling/</link><pubDate>Wed, 27 Oct 2021 13:18:20 +0200</pubDate><guid>https://fabiocarballo.github.io/blog/the_dangers_of_hyrum_law_in_domain_modelling/</guid><description>I recently got to know about Hyrum&amp;rsquo;s Law, when reading Software Engineering at Google. This is an informal law that was raised in the early days of Google and states the following:
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be dependend on by somebody
This law has several implications in different areas of software engineering, such as testing, deprecation, and domain modeling - and it directly impacts the code &amp;ldquo;maintainability&amp;rdquo; - since it indicates that the documented and tested behaviors may be a subset of all the expected behaviors.</description></item><item><title>Testing Hybrid Apps Flows with emptyComposeRule</title><link>https://fabiocarballo.github.io/blog/testing-hybrid-app-flows/</link><pubDate>Thu, 07 Oct 2021 11:17:22 +0200</pubDate><guid>https://fabiocarballo.github.io/blog/testing-hybrid-app-flows/</guid><description>Recently, we have migrated one of our app screens to Compose - in an experiment that reduced the UI layer codebase by 60%. However, by the time we wanted to test our app we found a problem.
At work, we have a small set of critical tests that we run as pure E2E tests. Therefore, every test starts by launching the app and traverse several different screens to verify that its expectations are met.</description></item></channel></rss>